50 years ago, Unix came from the future and showed us that less is more, and a good collection of composable tools can take you an awful long way. Along the way it’s evolved, demonstrating its flexibility and also suffered campaigns[0][1] by juggernauts like Microsoft demonstrating its durability. It (Linux - Potayto potahto.) runs every single super computer in the TOPS[2] ranking (500 entries) and has for the last 4 years.
I don’t actually know what iOS is, architecturally, but we know Android is also Unix (Linux), so it’s everywhere, serving us pretty well.
What’s not to like? What would you suggest instead?
iOS is a different OS but using the same Darwin core operating system, including XNU, the C library (+ a bunch of other ones) and launchd.
Unix command-line tools aren't present except the bare minimum for crash dump purposes on release iOS. The full set of BSD tools is present on internal builds and they're installed while jailbreaking.
I've learnt to become proficient on the Unix command line and vi over 30 years ago (on the company's own System V port, no less!). Best investment ever! Not only is it the environment most suited for development tasks, it also is consistently present on all systems I've worked on since. Navigating around Unix has long become part of my spinal chord/muscle memory. I can't count how many times I've heard the "man, we don't do the command line thing these days" meme. Like in late 90s from Windows fanboys. Or in 2000s from Java geeks who only knew their Java IDE and nothing else. Yet here we are working with clouds, containers, and FaaS based on POSIX principles.
People are not using 50 year old operating systems. It's not as if Linux or macOS today are the same as Unix even in the 90's! People are proud that certain ideas have persisted 50 years. People are proud because many things beyond Linux and macOS can be traced to Unix and the philosophy it holds, but also Unix's place in the broader story of computing history. Bell Labs, Thompson, Ritchie and many more played foundational roles. Like any other anniversary, it's nice to look back and reflect and celebrate.
That's like asking "Why are people proud to be using an Apollo-era pathfinding algorithm?". If it works, it works. The only reason that fashion is so fast in the tech world is that we have not really built many things that stand the test of time. Unix, for all its flaws, is one of these things.
Also, the Apollo era has some of the most amazing engineering achievements ever. Don't know why you would need to look down on that.
It's not an Apollo era OS though, any more than a new car is a 50 year old car.
They're both recognisably the same thing, but worlds apart - and have grown hugely in weight, power and included extras. I'm quite happy to find I don't have to keep relearning the basics of either. Whether car pedals in same place each time, or ps switches.
Is it really today (Oct 22)? Not that I care about the specific date, I'm just wondering if there's a particular story as to why this date. It'd be cool to hear if it exists.
Unix was ahead of its time in its inception, but that same basic design fails to address many of the current challenges we face as software developers and users, hence the proliferation of package managers, the mind-blowing complexity of userland middleware, the thousands of CLI tools each with tens of options and modes.
The simplicity of the basic Unix API means that much of the complexity is shifted elsewhere – in libraries, in middleware, in applications. Moreover, there is considerable overlap of functionality between many of these components.
Even worse is the security model of Unix: Users are considered a threat and are isolated, code is seen as trusted by the user and exploits are not considered.
The reality today are single user systems (And even if there are users, like for web services, the Unix user system is not used), where the code often cannot be trusted and almost always is exploitable.
It's a step in the right direction, but it's not as good as it could be, because it's hindered by compatibility with unix.
A native process on its own can't do much harm. Only with syscalls can it access other processes, the network, hardware, files, etc. Executing some random code shouldn't be dangerous.
First OS written in a high level programming language, without any kind of Assembly, back in 1961.
The systems language was an Algol derivative named ESPOL, later replaced by NEWP a bit more powerful.
Instead of requiring external Assembly support, ESPOL/NEWP have compiler intrisics for hardware access.
One of the NEWP improvements was the introduction of UNSAFE code blocks, any binary with unsafe code is tainted and requires being greelighted by the administration for execution.
We need a new UNIX-like moment in OS research. BeOS had interesting ideas in the 90s, but every single new OS now has to be "crippled" by POSIX to support *NIX, or else it has no critical mass to grow.
I'd like to see a MIT-licensed non-POSIX OS with a capable enough POSIX subsystem that would be eventually discarded as all software gets on board.
Kubernetes/orchestration/microservices is in this category imo. In a cloud environment, most of the facilities provided by the linux kernel are outsourced to the orchestration layer: security/access, process scheduling, persistence.
I think that’s a very strong statement that Linux “flourished because of GPL”, there are plenty examples of large successful OSS projects that use more lenient licenses.
It would probably be more accurate to discuss the people involved, the structure of governance of Linux, and the fact that GNU was mature enough to be the basis for a new OS.
Most likely not, but the reality is that in a couple of years GPL software might be relatively irrelevant in the FOSS world and we are back to shareware, public domain, demo licenses and such.
The problem with most research operating systems is the benefits are only achievable by rewriting userspace applications as well to take advantage. Given how long it takes to write a desktop environment and a web browser, it's not really surprising there isn't wider adoption.
What specifically do you want that can't be done as an extension to an existing GPL or BSD operating system?
Not a particular thing, but I believe existing OSs have too much baggage for truly mindset-shifting developments. And that's OK, no one wants to repurpose Linux to be something other than it is. But truly novel ideas would require something else IMHO.
That's what compatibility layers, emulators, and VMs are for.
And honestly writing a DE isn't that much work as long as you don't try to include everything and the kitchen sink. Really a DE's goal should be to get the hell out of the users way.
No, the big deal is drivers. Good luck getting anyone to use an OS that doesn't run on hardware they own.
Compatibility layers can kill your product, especially if it doesn’t yet have marketshare.
Developers will not invest in your APIs unless there is demand for it from millions of users (preferably users with money in their pockets), and possibly not even then (see OS/2 with its Windows compatibility layer)
If your OS doesn't offer anything that attracts users and developers to native applications then it is doomed anyway. Windows kept DOS compatibility for a long long time, but there were definite advantages to writing your applications for Windows so people did.
I also find it somewhat hilarious that you're so focused on profits in a thread about the 50th birthday of a family of operating systems best known for its free variations.
It appears that Beta 2 will be coming shortly. I would imagine that a 1.0 would follow in a year or so. Also I think it has been closer to 20 years now :)
I agree with Rob Pike that stated that systems software research is a dead end ... why reinvent yet another Unix like kernel in some C like language (Rust)
I want the Bill Gates intelligent software agents and way better sofware development tools (no-code is interesting).
time_t originally counted jiffies (60 per second) and was reset several times in the early 1970s before is was changed to count seconds. This makes it hard to interpret filesystem timestamps preserved in early Unix dumps. The 1970 epoch was chosen when Unix was a few years old, as a convenient round number.
"Development started in 1969
First manual published internally in November 1971[1]
Announced outside Bell Labs in October 1973"
https://en.wikipedia.org/wiki/Unix
I am confused: what would be the birthday of unix? Would that be an initial release or the start of development?
67 comments
[ 3.1 ms ] story [ 61.8 ms ] threadWe haven't found anything newer yet that works as well in both cases.
I don’t actually know what iOS is, architecturally, but we know Android is also Unix (Linux), so it’s everywhere, serving us pretty well.
What’s not to like? What would you suggest instead?
[0] https://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_...
[1] https://www.cnet.com/news/scalability-day-falls-short/
[2] https://en.m.wikipedia.org/wiki/TOP500
Unix command-line tools aren't present except the bare minimum for crash dump purposes on release iOS. The full set of BSD tools is present on internal builds and they're installed while jailbreaking.
The fact that is has Linux under the covers is pretty much insignificant and completely transparent to userspace.
Vaccines are older than Apollo, yet we still depend proudly on them.
The written language is even older, and it is still the justified source of a lot of human pride.
Also, the Apollo era has some of the most amazing engineering achievements ever. Don't know why you would need to look down on that.
It's not an Apollo era OS though, any more than a new car is a 50 year old car.
They're both recognisably the same thing, but worlds apart - and have grown hugely in weight, power and included extras. I'm quite happy to find I don't have to keep relearning the basics of either. Whether car pedals in same place each time, or ps switches.
A lot of other stories mention "summer". e.g. https://arstechnica.com/gadgets/2019/08/unix-at-50-it-starts...
At varsity we had the misfortune to using Sperry 1100 Univac system ... all I can remember it sure had a lot of "@" in it's JCL to get anything done.
Third year we got a NCR "Tower" Unix system ... what a joy in comparison.
The simplicity of the basic Unix API means that much of the complexity is shifted elsewhere – in libraries, in middleware, in applications. Moreover, there is considerable overlap of functionality between many of these components.
The reality today are single user systems (And even if there are users, like for web services, the Unix user system is not used), where the code often cannot be trusted and almost always is exploitable.
A native process on its own can't do much harm. Only with syscalls can it access other processes, the network, hardware, files, etc. Executing some random code shouldn't be dangerous.
Not really, plenty of other OSes came before UNIX, some of them still being sold to this day, e.g. Unysis ClearPath MCP.
The systems language was an Algol derivative named ESPOL, later replaced by NEWP a bit more powerful.
Instead of requiring external Assembly support, ESPOL/NEWP have compiler intrisics for hardware access.
One of the NEWP improvements was the introduction of UNSAFE code blocks, any binary with unsafe code is tainted and requires being greelighted by the administration for execution.
It was originally known as Burroughs B5000, https://en.wikipedia.org/wiki/Burroughs_large_systems.
Naturally Unisys uses the security and data integrity theme as the target segment for getting a ClearPath MCP toy.
https://www.unisys.com/offerings/clearpath-forward/clearpath...
https://www.youtube.com/watch?v=xatHCXEkOsY&list=PLzXIyqnmO3...
There are also Visual Studio plugins for developing remotely with ClearPath, https://www.youtube.com/watch?v=IHLx1Bc4lH0
A recent version of NEWP reference manual can be found at https://public.support.unisys.com/aseries/docs/clearpath-mcp...
— Dennis Ritchie (1941–2011)
I'd like to see a MIT-licensed non-POSIX OS with a capable enough POSIX subsystem that would be eventually discarded as all software gets on board.
I'm not sure that the MIT-license would have had the same impact on an opensource OS...
It would probably be more accurate to discuss the people involved, the structure of governance of Linux, and the fact that GNU was mature enough to be the basis for a new OS.
What specifically do you want that can't be done as an extension to an existing GPL or BSD operating system?
And honestly writing a DE isn't that much work as long as you don't try to include everything and the kitchen sink. Really a DE's goal should be to get the hell out of the users way.
No, the big deal is drivers. Good luck getting anyone to use an OS that doesn't run on hardware they own.
Developers will not invest in your APIs unless there is demand for it from millions of users (preferably users with money in their pockets), and possibly not even then (see OS/2 with its Windows compatibility layer)
I also find it somewhat hilarious that you're so focused on profits in a thread about the 50th birthday of a family of operating systems best known for its free variations.
Haiku, well, let's hear it from one of the developers:
> Haiku is a POSIX system, yes. Why is that an issue?
> -waddlesplash [0]
[0] https://news.ycombinator.com/item?id=17441874
https://en.wikipedia.org/wiki/Windows_Services_for_UNIX
I want the Bill Gates intelligent software agents and way better sofware development tools (no-code is interesting).
iOS has even been dropping parts of it, e.g. the new network stack.
But yeah, non-UNIX ideas on new OS research are more than welcomed.
https://www.unixgame.io/unix50
Ever want to know what Unix v1 was like on the PDP-11?
I am confused: what would be the birthday of unix? Would that be an initial release or the start of development?