> This naively (or maliciously perhaps) maintains that the "purpose" of the certificate is to identify an entity. [...] identity is not the primary purpose certificates serve in the real world.
Identity is the only purpose that certificates serve. SSL/TLS wouldn't have needed certificates at all if the goal was purely encryption: key exchange algorithms work just fine without either side needing keys (e.g. the key related to the certificate) ahead of time.
But encryption without authentication is a Very Bad Idea, so SSL was wisely implemented from the start to require authentication of the server, hence why it was designed around using X.509 certificates. The certificates are only there to provide server authentication.
> Smalltalk and another esoteric programming environment I used for a while called Frontier had an idea of a persistent data store environment. Basically, you could set global.x = 1, shut your program down, and start it up again, and it would still be there.
Frontier! I played with that way back when on the Mac. Fun times.
But as for programming language with integrated database... MUMPS! Basically a whole language and environment (and, in the beginning, operating system) built around a built-in global database. Any variable name prefixed with ^ is global and persistent, with a sparse multi-dimensional array structure to be able to organize and access the variables (e.g. ^PEOPLE(45,"firstname") could be "Matthew" for the first name of person ID 45). Lives on today in a commercial implementation from Intersystems, and a couple Free Software implementations (Reference Standard M, GT.M, and the GT.M fork YottaDB). The seamless global storage is really nice, but the language itself is truly awful.
TADS, an OOP language + VM for interactive fiction, has this "value database" model. Once loaded into memory, the compiled image can be updated with values stored in a separate save file. The compiled image itself could store updated values as well.
In fact, it does this during a "preinit" stage that runs immediately after compilation. Once all preinit code finishes executing, the compiled image is overwritten with the updated state. The language includes a "transient" keyword to permit creating objects that should not be stored.
This same mechanism permits in-memory snapshots, which are used for the game's UNDO feature. No need to rewind or memento-ize operations, just return to a previous state.
It's not a general-purpose mechanism. After all, the language is for building games with multiple player-chosen save files, and to permit restarting the game from a known Turn 0 state.
The MUMPS database is wild. When I was working in MUMPS, it was so easy and fun to whip up an internal tool to share with my coworkers. You don't have to give any special thought at all to persistence, so you're able to stay in the flow of thinking about your business logic.
But as you said, the language itself is almost unbearable to use.
Image persistence was one of the cool ideas of Smalltalk. And in practice, one of the biggest drawbacks. Cruft and old values accumulated steadily, with very little way to find and eliminate them. Transient execution has some cons. But on the pro side, every run starts from a "clean slate."
Save image... for short-term convenience; build clean every week from archived text files.
----
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager."
I believe it's just a git repo behind the scenes. Not sure if the UI exposes those things as I never used that in multi-developer scenarios!
Give it a go and see.
This may fall in the "you think you do, but you don't category", but I've always wanted a Smalltalk (or similar, not that picky) with a persistent virtual memory.
That is, the VM is mapped to a backing file, changes persisted automatically, no "saving", limited by drive space (which, nowadays, is a lot). But nowadays we also have vast memory space to act as a page cache and working memory.
My contrived fantasy use case was having a simple array name "mail", which an array containing all of my email messages (in email object, of course). Naturally as you get more mail, the array gets longer. Also, as you delete mail, then the array shifts. It's no different, roughly, than the classic mbox format, save it's not just text, its objects.
You can see if you delete a email, from a large (several GBs), there would be a lot of churn. That implies maybe it's not a great idea to use that data structure, but that's not the point. You CAN use that data structure if you like (just like you can use mbox if you like).
Were it to be indexed, that would be done with parallel data structures (trees or hashes or whatever).
But this is all done automagically. Just tweaks to pages in working memory backed by the disk using the virtual memory manager. Lots and lot of potential swapping. C'est la vie, no different from anything else. This what happens when you map 4TB into a 16GB work space.
The problem with such a system, is how fragile is potentially is. Corrupt something and it happily persists that corruption, wrecking the system. You can't reboot to fix it.
Smalltalk suffers from that today. Corrupt the image (oops, did I delete the Object become: method again?), and its gone for good. This is mitigated by having backup images, and the changelist to try to bring you back to the brink but no further.
I'm guessing a way to do that in this system is to use a copy on write facility. Essentially, snapshot the persistent store on each boot (or whatever), and present a list of previous snapshot at start up.
Given the structure of a ST VM you'd like to think this is not that dreadful to work up. I'd like to think a paper napkin implementation PoC would be possible, just to see what it's like. One of those things were the performance isn't really that great, but the modern systems are so fast, we don't really notice it in human terms.
> oops, did I delete the Object become: method again?), and its gone for good.
And then you admit actually it's not gone for good because if you created the method that will be recorded in the changes.log file and if it was a provided method that will still be in the provided sources file.
Have you looked at Pharo? Their git integration makes it relatively easy to export and backup parts of your main image, and to pull the things back into a fresher one once you mess up.
> 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.
All coconut trees are palm trees, but not all palm trees grow coconuts.
reply