> I would like to note that Linux is the only kernel which will allow you to do this!
I'm pretty sure that MVS syscalls (that is, the numbers you use with the SVC opcode) have remained backward-compatible at least as far back as MVS 3.8 in the 1970s and those binaries making those "raw" syscalls will still work on the latest z/OS releases.
There are a _lot_ more operating systems than Linux, Windows, and the BSDs... making a statement that the Linux kernel is the only kernel to do something a certain way is a risky proposition :-)
That's awesome. I didn't know about that system and never thought to look for it. Can you point me towards documentation where the vendor promises the interface will remain stable and backwards compatible? I'll remember it.
Chapter 16 is named "No Silver Bullet—Essence and Accident in Software Engineering."
I'll type out the beginning of the abstract at the beginning of the chapter here:
"All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement."
From the abstract that definitely sounds like he meant "incidental": Something that's a necessary consequence of previous work and / or the necessary but simpler part of the work.
"Documents must be utf-8 and should have a byte order mark."
No. If you're using UTF-8 (which is a good choice), the use of a BOM should be discouraged. Given that the format specification says documents MUST be UTF-8, there is no need to enable detection of UTF-8 content with the UTF-8 BOM. And, of course, the original purpose of the BOM (detecting big- or little-endian encoding) is unnecessary in UTF-8.
The Unicode standard, section 2.6, says, "Use of a BOM is neither required nor recommended for UTF-8".
While it is allowed, if you're making a new spec for a new data format, you shouldn't recommend the use of a BOM in UTF-8.
> Do they still use 0-terminated strings/char* as the main string type?
Of course, it's still C.
> Is the usage of single linked lists still prevalent as the main container type?
As far as I can remember, the C standard library has never had any functions that used linked lists. Nor are there any container types, linked lists or otherwise, provided by C. So I'd say this is a question about how people teach and use C, not related to the language -- or language spec version -- itself.
It doesn't matter who "owns" it (the country probably outsourced management of it to another entity, I assume); the domain exists because it exists as an ISO country code. When the country is no longer a country, and the IO country code is removed from ISO 3166-1, the justification for the domain existing will be gone. The article is saying that per current IANA policies, that should trigger the domain to be retired over a period of several years.
Personally, I do find it highly unlikely the domain will go away. They'll do something to keep it around. As the article states toward the end, "The IANA may fudge its own rules and allow .io to continue to exist. Money talks, and there is a lot of it tied up in .io domains."
ISO 3166-1 defines codes for "countries, territories, or areas of geographical interest". When the country is no longer a country, the country it's becoming part of might very decide to treat it as something still deserving an ISO code and thus a ccTLD. (and such a status makes sense for pure geographical reasons, its >2000km from Mauritius)
I believe the reasoning is that the list was originally used for post, so far-flung regions of a country may have their own codes, even if they're not politically separate. GF, French Guiana, is a good example. Politically, it's merely a region of France, but it still gets its own code.
If Mauritius decided to used a variant of Chagos/Chagas (so probably CS, since that's the only available code that still somehow fits) then IO will probably be ejected from ISO 3166.
The article addresses this: what happened with .su is part of what caused ICANN/IANA to update their policies to not have defunct country codes stick around.
Additionally (and more importantly), SU is still reserved in the ISO 3166 list (https://www.iso.org/obp/ui/#iso:code:3166:SU), so if United Kingdom somehow convinced ISO 3166 MA to reserve IO then it will be messy.
Ironically, there's some unintended truth in their reference (i.e. to all intents and purposes the KGB hasn't gone anywhere and basically is still around, just renamed/reorged) but that's an entirely different thread.
KGB was split to what is now SVR (ex 1st main department) and what is now FSB (2nd main department), with some other organizations taking remaining roles.
These days however, the Russian intelligence landscape is more complicated, with multiple semi-private organizations, informal groups, and other stakeholders.
Seemed like the definition of "programming language" was quite odd (given the title of the submission to HN is "Where are programming languages created?"), but then I noticed the actual title of the page is "Where does software innovation happen?" and is not restricted to programming languages.
While Kotlin is a Russian island the Kotlin programming language was created by JetBrains which is a Czech company founded by Russians with headquarters in Prague. You will find Kotlin on the map in the Prague circle.
They shut down their St. Petersburg office and their Russian entity after the war started. At this point many of their people are outside Russia; all over Eastern Europe mostly. Lots of their Russian employees emigrated.
Notably, Roman Elizarov who was leading the Kotlin team and who is based in St. Petersburg actually left Jetbrains. It's not clear why; at the time he cited personal reasons. But reading between the lines, it could be because he was not able or willing to leave Russia.
The Czech office is a flag of convenience. Until the full-scale invasion all development of this Russian named product founded by Russians was happening in Russian Federation. But formally you have a point.
As far as companies with a Russian origin go JetBrains and Yandex are at complete odds with each other. JetBrains condemned the Russian invasion of Ukraine and suspended sales and R&D there shortly after the war broke out then left the country entirely as soon as they relocated the employees. Whereas Yandex stayed and as a result their home page today is chock-full of Russian propaganda. JetBrains may have originated in Russia but they have nothing to do with that country anymore so counting them in with Yandex is wrong.
Yandex has no way out of Russia. Most of its businesses are russian-targeted and going “full outside” makes zero sense for them, because to continue they’d have to bow before authorities anyway. As a media company, to condemn the war for them meant being instantly raided and re-owned, which sure isn’t far from truth, just was less dramatic.
Agreed that exiting the country was much easier for JetBrains who are more internationally focused. But my belief is that Yandex leadership made a strategic mistake in not spinning off their core businesses to Europe. They had a chance at establishing themselves as an EU-first search engine, mail provider and cloud that can compete at the equal footing with Google. Yet they blew it and now they are FSB owned in everything but name.
Wow, this is one of the worst articles I've ever seen. Aside from the obviously false information about Windows 3.1 and Windows 95 mentioned in other comments, the article just drops in this statement at the end:
"This is also precisely why military aircraft, like the Air Force One, still use needles, dials, and gauges—you cannot beat the reliability of older systems that have already been put through the wringer."
Gonna need a citation for that! The two jets used for Air Force One are based on the 747-200, which was one of the very early 747 models, so of course it predates glass cockpits. The reason isn't "precisely" because analogue gauges are more reliable, it's because of the plane's age. Look at all military aircraft development and you'll see they use the technology of the era. The replacement for the current VC-25 (Air Force One) aircraft will be based on the 747-8, and you better believe they'll have the glass cockpits now in use in the latest 747s.
I run a multi-user Linux server. It's IBM POWER9 hardware and several of my friends in the open-source community who care about testing on something other than x86, or who are interested in different architectures or playing with its unique capabilities such as quad-precision floating point implemented in the hardware appreciate having shell access to it.
I'm pretty sure that MVS syscalls (that is, the numbers you use with the SVC opcode) have remained backward-compatible at least as far back as MVS 3.8 in the 1970s and those binaries making those "raw" syscalls will still work on the latest z/OS releases.
There are a _lot_ more operating systems than Linux, Windows, and the BSDs... making a statement that the Linux kernel is the only kernel to do something a certain way is a risky proposition :-)
reply