>However, the Crimea is quite different in one key respect: most of its people, being Russian, prefer to be in Russia. In fact, one can
>argue that it is in the political interest of Ukrainian nationalists to have Crimea in Russia. Without the votes from Crimea, Viktor
>Yanukovich would never have been elected president.
This is actually a very interesting point, and would explain Ukraine's recent shift to more nationalist politics, and pivot away from Russia - which (unintended consequences for Russia) sparked all these problems in the east.
I dunno how accurate this is, but back when protests against Yanukovich started, I saw people on reddit predicting his ouster and civil war, because of the history of Poland...
Seemly Poland in the run up to WW2 got parts of it conquered by URSS, and later when WW2 was over, some territory that was part of Germany became part of Poland to "restore" its territory, effectively shifting Poland westward, this means that eastern Ukraine had polish people inside it.
The guy then explained that Ukraine east side is full of ethnic Russians, even if they consider themselves Ukranians, while west side is filled with ethnic Polish and related groups.
He predicted then (the violent protests didn't had started yet when I read this) that the ethnic EU people would be pro-EU, and would oust Yanukovich in violent protests, and the ethnic Russians would retaliate in some form, either trying to retake the capital by force, or splitting away.
The part of Poland that was annexed during WW2 had 3 major ethnic groups there - Polish people, Ukrainians and Jews. Most of the Jews got executed during the war, Polish were sent back to Poland by Stalin.
Yet culturally Western Ukraine has much less ties with Russia, due to not being a part of Russian empire.
Again and again, I read this 'ethnic' treatment of conflict in Ukraine. That is not true, for example Kyiv is majority (even today) Russian-speaking, yet it always supported pro-West politicians in elections.
>the energy grid of the region is still very tied into Russia which is of a critical concern right now
This however makes the relationship somewhat symbiotic, as Russia also depends on EU money. I remember reading recently (somewhere?) that Russia had transitioned from a failed industrial state to a failed Petrostate sometime in the 90's since that's currently their biggest source of foreign currency.
Another point I'm surprised I don't see anybody making is the impact of drones on armoured assaults. The recent conflict (Tajikistan / Kyrgyzstan ?) showed that they could really devastate attacking armour, and last time Russia 'holidayed' in Ukraine it was their stronger armour that pushed the Ukrainians back. This could really tip the balance back to the defenders. Also, it's hard to deny you've invaded a country if 100 of your tanks are smouldering wrecks on the wrong side of a border.
It would actually be nice if the developers of these old applications would upload their source somewhere so that enthusiasts can build on them.
GNUSTep is an implementation of the Openstep spec, so there's a good chance that that old software could be ported to Linux (or even OSX) without too much effort.
download source code
./configure
make
sudo make install
seems to work for lots of software. By default it should install in /usr/local/<bin/lib>
but I've done this for lots of OSS software (e.g. postgres and nginx) on Mac with few problems.
Yes, sometimes you have to pursue the odd missing dependency and build that too (e.g. openssl or readline), but I've
always managed to build from source in the end without brew or (what's the other one called?).
Fair enough, but I have never observed another MacOS user in the wild compile from source.
No matter the risk, every engineer I know uses brew.
MacPorts is the other one and it at least uses some crude bulk openssl signing, but the higher barrier to entry means fewer packages so devs don't use it.
>Most employment contracts are actually enslavement when it comes to IP
Note this is a mostly US perspective, e.g. AFAIK in Switzerland what you do in your own time, and with your own equipment is entirely your own under Federal law. And that seems totally fair.
Of course if you steal code or ideas from your employer, then things get a bit more grey.
Do you have relevant sources for this? AFAIK some Google Switzerland employees are still bound by this stupid rule (what you do in your free time, with your personal device, is still Google's property), but I would love to be proven wrong.
But it only takes one losing side to decide - Fuck it, we're losing so 'fire all your guns and explode all in space' to destroy everything in orbit with a massive amount of debris that'll last for years.
Russia's little test a few weeks ago showed how that might be.
So hopefully that's the MAD scenario that will keep peace in orbital space for a while yet.
Windows 95 & 98 would crash pretty frequently. Not as badly as win 3 though.
NT 4.0 was no bastion of stability either. Windows didn't stabilize until well after Win2000 versions.
MacOS 7 & 8 also not great. The first versions of OS X were also pretty flaky.
In my experience dependable reliability of workstations and servers didn't happen until the mid-2000s
where just software couldn't simply blue screen an OS, or lock it up forever.
If I remember rightly it was about that time that MS got serious about driver reliability, which seemed to
help a lot.
The middle versions seem to be the best ones somehow. Sire, the cooperative multitasking model of Mac OS 9 was a bit, crappy, but it was really reliable if you went to work at it from a task-oriented perspective. Same for Windows 2000, more stable than Windows XP for some reason.
For Mac OS X it was 10.3 to 10.5 that was the (seemingly) most stable.
I think the scope and size of hardware, software and interaction has just gone so large that it's not commercially viable anymore to test or QA the entire system to the same standard. It's also why service managers came along, we just assume that everything breaks and hope restarting it makes it go away...
My recollection of (Apple's) System 7 is that it really got bitten by the rise of programs running dynamic code (i.e. Netscape). When everyone was operating on relatively pre-vetted apps, which had their buffer overflows cleaned up, it played pretty nice, but when that wasn't the case, it really blew up.
System 7.5 was rather worse-off than 7.0, but it got absolutely slammed because it was the first major mac OS that got saddled with web browsing, and the OS was just not fit to handle apps that had buffer overflows.
That was the big thing about those mac OSes; since they had no memory protection, if any app on the system buffer overflowed, it'd crash everything. It was fine in an environment where you really were only running one or two apps that were known to be really rock-solid, but it wasn't able to police misbehaving apps.
Maybe they're not talking about the currently surviving mainstream consumer OSes? There were other contenders that weren't for consumers or didn't survive MS's bullying, and on the other end there's probably a reason mainframes are still in use in places.
The context here is desktop systems, not mainframes.
Though the interesting takeaway from your comparison is the fact that desktops these days run server kernels, which is a testament to the build quality of servers.
Which segues nicely into a recap of my point: 90s desktop systems didn't have memory protection et al so one buggy application would cause the system to crash. Everything was carefully layered like a house of cards. The switch to NT and UNIX largely fixed most of those issues but later builds of macOS seem as buggy to me as Win 9x and MacOS 8 and 9 were.
You're conflating workstations with personal computers.
In the 90s systems like OS/2 and NeXT were defined as "workstations" to make a distinction between the old lineage of personal computing platforms (like Win 9x and Mac OS running on typically budget hardware) from high end systems running typically multi-user systems (often literally mainframe OSs).
Post-90s and the "workstation" definition went away when NeXT became OS X and NT replaced the DOS-bootloaded Windows lineage; and dedicated workstation hardware became cost ineffective due to improvements in consumer hardware -- not least of all x86 (and later AMD64).
I personally love stored procedures, and Postgres, MSSQL, Sybase and Oracle all provide pretty good languages to implement them in.
In my experience the most reliable and long living projects treat the DB as its own separate product, whose interface to data mutation is via stored procs. The db can then be sanely designed with good data integrity rules (foreign keys, unique indexes and data column constraints).
Then external callers use the stored procs as their API, and then mostly don't have to worry about the internals. You can easily create a web based client, REST calls or a native GUI app that all work directly off the same db.
However they do have to worry about :
-connection timeouts
-query timeouts
-deadlocks
That's largely because alternatives like Postgres exist. If they didn't then I'm pretty sure the the conversation would be more along the lines of "take it or leave it."
People shouldn't underestimate the commoditization of databases that has occurred since MySQL and Postgres became acceptable alternatives.
Has nothing at all to do with Postgres, or underestimating anything. Microsoft has a very large, robust partner network that's able get great pricing and the cost of MSSQL really hasn't changed much over the years outside multi-core updates.
>argue that it is in the political interest of Ukrainian nationalists to have Crimea in Russia. Without the votes from Crimea, Viktor
>Yanukovich would never have been elected president.
This is actually a very interesting point, and would explain Ukraine's recent shift to more nationalist politics, and pivot away from Russia - which (unintended consequences for Russia) sparked all these problems in the east.