Project Oberon
projectoberon.com
projectoberon.com
Why am I imagining this? I feel like computing systems as they've evolved, they've built stuff on layers upon layers and just like biological evolution, it is impossible (difficult) to undo because the marginal cost is too high to unwind and break backwards compatibility. We get stuck in local maxima at each layer and the critical energy required to escape out of it would be too large.
I am not saying backwards compatibility is bad, far from that, I am saying that if we force ourselves to cut the cord and completely build computing systems from scratch - I feel like we would have a hindsight to design it better, faster, and cheaper.
But ultimately a computing system should do what its users want, and the market has favored backwards-compatibility for a long time. If anything, it's a little alarming how old software and hardware can quickly become useless or obsolete. For example, any web browser that doesn't support any encryption better than, say, SSLv3, is cut off from a significant fraction of the Internet.
I respectfully disagree. Alien systems can be thwarted by inverting some bits. [0] I would not have believed this had I not seen it for myself. [1] After all, seeing is believing. True, the alien code seems very insecure. Perhaps aliens write their code based on the historical documents. [2]
[0] https://www.reddit.com/r/movies/comments/2oi7cz/i_am_dean_de...
To build a system, you would have to start at the bottom layers and then build up. To think you could design any of those layers (protocols, languages, tools, etc.) without making mistakes is naive and I think you would end up with a system that is layered just like current systems, but each layer being much less thought out. Yes, that is even with complete hindsight. I have watched many experienced teams fail on gen 2 of systems.
Don't get me wrong, there are many things I dislike in computers, starting with autotools :) But things like autotools are a lot easier to replace in Hacker News comments than in real life.
Do you really think that it would be less thought out if we have lots of resources and smart people? I feel optimistic that we can bake in the lessons from the past and improve on existing layers/stack/protocols.
But we can also invert our perspective and ask: Will there a dramatic shift to a New Way in the next half century? Since 1970 there have been at least 3 major transitions in how people work with technology, it’s easy to imagine more will come before 2070.
1. 1980s – 1990s Mainframe to PC
2. 1990s – 2000s PC to Web
3. 2000s – 2010s Web to Mobile
In each of these transitions the software written for the Old Way was incompatible with the New Way.
(There have also been shifts in data storage and network protocols that others might point to as major transitions.)
IMO hierarchical deep menus are logical but they take up precious time when you need to do that action 80 times a day. Same benefits can be obtained by well designed layout (with borders, background colors and proper labels).
Most people would find that dauting. I think hiding stuff behind menus is not a good idea even though on surface it might feel like making it less complex. In fact, the complexity is the same, just visual clutter is reduced. I argue that we're really good at looking at visual clutter, my professor's desk is a good example of that.
For the operating system layers, if you build a machine that doesn't expose an ISA, in which all code is run via a polyglot VM like the GraalVM/JVM, then you can more easily design a competitive CPU because suddenly you can use flat, direct physical address space mappings with an ISA that is throwing out old instructions whenever you need to. No need for an MMU, TLBs and all the other page table walking logic, IPC can be drastically simplified.
Singularity / Midori was the most complete exploration of this concept, by Microsoft Research. Unfortunately they kind of went down a few bad R&D paths, in particular, by trying to match the performance of C++ code and relying too much on formal methods - i.e. all stuff interesting to implementors - instead of researching things interesting to developers.
That's why the right way to re-invent computing is top down, not bottom up. Take an existing Linux distro and start to replace bits one step at a time, starting with the desktop environment, the app and data models, network protocols etc. But all the drivers and filesystem goop remains the same - limited potential for innovation there. That said, if you want to, these days you can reimplement drivers in userspace using whatever framework you like, reducing Linux to basically a fat microkernel.
If we had lots and lots of really smart people working on a new version of everything, though, my guess is that we would end up with pretty much the same stuff we have today. As another commenter said, a lot of software projects doing next gen rewrites from scratch fail. The reason is simple: they focus on solving painpoints and forget about the areas that were neatly addressed by the previous architecture.
The best approach IMO is to address the painpoints by refactoring them properly into the architecture. That is often very complex on its own but still has the best chance of succeeding.
I think it is extremely important from a teaching and engineering perspective to view the modern computing environment not as some elegant design (which it most certainly is not) but instead as an concretion of "best option at the time" solutions to real problems.
It is a bit intoxicating to think about how things could be if computing really were approached as a single, monolothic, elegant design. But essentially every attempt to do so has failed. Much like how we think of computing as layers of abstraction, the computing industry is functionally constructed of layers of abstraction, and so it is difficult to really change anything at lower levels.
On the other hand, the current internet feels like a good approximation of the best trade offs for performance vs. usability in most areas, and I doubt a full rewrite would fundamentally change much about how we use the internet.
I imagine that it would in fact have to support people using the internet exactly the way they do now, if it hoped to get traction.
An Internet where “keep engagement high so we can serve shitloads of ads” was not the default path to financial success would be an Internet without social media that happily pushes people into ever-more controversial positions, because that’s what keeps them around longer and lets you serve more ads. Decide for yourself what social changes that would create.
In areas like music and video streaming, paid services are actually popular, because they have a different cost structure and more consumers find it worthwhile to pay to access better content with no ads.
The problem is indeed greed, but I'm not sure the banks are the ones who are greedy here.
Sure there is, they'd lose enormous money that way. Because the small segment of users that would pay for the average page view are a large portion of the users most valuable to advertisers.
If they charged high enough to make up for the loss of the demographic willing to pay the price, it would be an even smaller group paying very high prices. And even higher prices once you charged extra to recover the costs of developing and maintaining the separate payment and customer support system and service for that small customer base.
Lots of people that are in demographics more valuable than average see stats about the average a site makes per view (or per MAU, or whatever) and says “I'd be willing to pay more than that.”
What they don't realize is that they are worth more than that as advertising targets, and the people that bring the average down to what it is aren't willing to pay the average.
That was extremely low friction, but would still be too bothersome for a micropayment. If any such model wants to have success, it will need to be completely frictionless, with absolutely no interaction required. And it would need to work automatically everywhere, e.g. built into the ad services themselves. There are attempts (e.g. https://contributor.google.com/v/beta) but that's not quite as easy as it should be.
What would happen if I had Apple Pay set to Face ID for confirm?
Is this really an Apple Pay request, or is it a look-alike?
Thanks!!
Perhaps there could be a new digital currency for all and any transactions done online. Let's call it ICR. Websites and apps would only accept ICR, and pay out only in ICR, and people would convert between ICR and whatever they want, and that would be the only way to generate ICR, unlike cryptocurrencies and whatnot.
Ads still all over.
In contrast to op assuming built in payment would have had replaced ads.
As bad as ads and tracking are, they truly enable everyone to use the internet, no matter the background, financial or legal status, age or nationality. In my view, that makes up for all the problems tracking causes.
If someone goes full-on "modern internet experience" without ad blockers, third party script blockers, cookie blocking, canvas fingerprinting blocking, etc. etc. the dataset collectable from the user behavior is rather large. And this allows for a detailed profile of the user to be built over time.
But what for? Why so much detail? Why so pervasive collection of online behavior and real-life interests? To sell more things to people? It seems like advertising would work just fine with a much coarser scale. Is it something more exotic, like building a "digital twin" of every citizen out there to predict what they will do and how they behave?
Or can it just be the mundane ads?
Anyway, I've wondered those questions and namely why the profiling part must be so pervasive and massive in scale. Can it not work in lower resolution?
PS. The TV-series Colony contains one possible "answer" but although it is an entertaining and paranoid thought, the real-life plausibility of that answer is rather low :)
Sounds like a ML model that can do correlation but can't handle causal and counterfactual reasoning.
Isn't the iPhone/iPad supposed to be exactly that?
A single device, a single ecosystem, a single curator.. and outside of a vocal minority, millions of people love it for exactly those reasons.
It's just a skin on top of the same old stuff everyone else uses, but with more control so you can't reach underneath to see much of the foundation.
That said, it's a fairly deep skin by this point, and getting deeper, but compared to the whole depth of the stack we're talking about, it's still just the skin.
While I don't know enough to comment authoritatively on it, I think with respect to this Apple might have taken a step backwards (at least with respect to percentage of system that is unique, if not in total amount of libraries and code) when it switched to OS X. OS 9 and its prior versions were an entirely unique and custom OS designed at Apple. The whole switch to OS X was taking a UNIX core for stability and building on top of it.
Apple systems are quite different than the norm in many respects, but the scope of this discussion is so large that there's really little they do that's different than everyone else from that perspective, because nobody does anything different. It's hard to start from scratch and ignore approximately 80 years of concerted computer science effort and come up with something useful and usable in any sort of time frame that makes it worthwhile.
I’m a software engineer, I’m perfectly well aware iOS and MacOS run on top of a Unix kernel. But unless I go looking for it, they will never shove this in my face and make it my problem.
Meanwhile, I’m still dealing with Linux-loving colleagues who cannot get their sound or webcam to work reliably and consider this an acceptable state of affairs.
That's largely the fault of manufacturers who refuse to properly document their devices and release functional drivers. I don't think anyone considers that an acceptable state of affairs, merely tolerable if it allows using an open software stack that you can freely modify.
This isn't so much of an issue anymore in my experience. Older webcams and sound cards that work flawlessly with Linux often don't work with newer Windows versions, though.
I've programmed for two decades. I write non-trivial software modules in a specific domain. It's not as if I was averse to analyzing things. And I try. When I can.
Yet. Design is damn hard.
One of the problems is that implementation is often an empirical process of requirements and constraints recovery.
I.e. I cannot create an elegant design before I've implemented anything, because some of the requirements are discovered only when the domain is explored using the code which I write.
One of the problems is that I'm not smart enough to design the system beforehand. And I don't have enough working memory to do so. And I presume many programmers work in similar environments.
I think in the 70's or 80's there was a vivid dream that one day programmers would have advanced CASE tools to help them design better programs. I wonder what happened to that dream. Maybe IDE:s and software systems became so easy to use that everyone prefers to prototype in code and perform empirical constraint discovery just like me...
And as most of the business value lives between the UI and the database, I understand why there is no driving incentive to create similar high quality tools for numerical, data intensive programming tasks that run on the customers desktop. We work in a niche, hence must be self sufficient.
I've spent (in bizdev, e-gov) tons of time figuring out badly structured data, fixing data quality issues, handling tons of administrative tasks to access sensitive data, etc.
I think it's up to a point where the structure of the databases actually influence the structure of the government. That's because nowadays, the databases and the business rules they embody are so complex that even the civil servants tend to forget how they work.
The assumption was that the communications structure would come first and then the design would imitate it, but with really ossified hard-to-change systems it seems plausible that the departmental organization would shape around it.
How often is that the case these days, though? Currently, when I subscribe to a service or buy a product tied to a service, I feel there's a 50/50 chance the company will shut down the service (or itself) while I'm still using it.
If you got capable developers, let them do their job and create a flexible (expecting changes, simple design, usually not an elaborate many classes design) solution, that actually fits your situation. Developers are (should be) abstractions specialists. They should be able to find working ones in most cases.
Or live with limitations and the spread of thinking, that some things are not possible in various appartments. Mental barriers, that stop creative thinking, simply, because the tools do not exist.
I think that's a bit harsh - a lot of these tools can be pretty powerful if they are used for the kinds of tasks that they are well suited for. However, stray into a task that is just that bit more complex than what they are good for and they can be an utter nightmare.
Of course, deciding whether a particular task is a good fit for a particular tool can itself be a tricky question.
In my experience, they are at most two of these things. Most of the time, I see lots of businesses bend over backwards to mold their processes to match the tooling they use, or expend lots of manual labour because their business flow isn't modelled efficiently in their tooling. Impedance mismatch is the #1 factor why many business automation projects end up costing multiples of what they were initially intended to save.
These problems aren't limited to off-the-shelf solutions, it could take an experienced developer months to really learn the business process and model it efficiently. Most businesses don't allow for that in their software budget, so you get either:
- something that works, and is relatively cheap, because it was cobbled together by someone from the business (see: excel sheets, access applications or nowadays, Microsoft Flow)
- something that works and is efficient, because it was built by a team of developers in close cooperation with the business
- something that's cheap and efficient but doesn't work, because it was built by a fly-by-night developer on a shoestring budget.
The only cases where you can have all three is when the business was built around a single piece of well-designed software, the CTO and CEO have been very conscientious about following the capabilities of the software, and the software manufacturer never decided to completely overhaul their interface for "reasons".
E.g. we have a bunch of stuff in Airtable. It's great. You can do amazing stuff with it, and it has a great API for most things.
Except for the change history and comments.
When you're aware of this, it is fine, but the moment your business processes start depending on using the comments and change history, you're locked in unless you're willing to use phantomjs or similar to log in and use the API (of course there is one) that their web client uses to access the comments, in a way that is a massive pain.
I'm happy for users to start building stuff and automating stuff. The bigger problem is when they don't design and don't understand the trade-offs. Often it works great for years, until it doesn't and you have a massive job untangling dependencies in some cobbled together solution.
Sometimes that is worth it.
Sometimes it causes you to incur costs far higher than what you saved initially because knowledge often gets lost as these system grow in complexity without any coherent thought behind them.
Very often, even if you end up using these tools, you'd still be far better off if there was still a review process to get someone to say "stop,if you do it this way you're creating a risky dependency, do it this way instead." Or to say "we really need the dev team to handle this."
Everybody has a plan until they get punched in the mouth…
- Mike TysonEssentially in FP you design your entire program as a single immutable function expression that's made out of a pyramid of layers that's constructed of smaller closed lego like functions composed together. People in the FP world call it the point free style.
The type signatures guide the architecture of your program and can easily be replaced decomposed or recomposed into higher or lower forms of abstraction without compromising your overall program. Design comes naturally like building something out of legos... Easily configurable, and minimal planning or need to hold the entire program in your head. If the design is wrong like legos your program is easily reconfigurable.
The main factor that allows lego like design is immutability. A lego that mutates state outside of its own scope is a lego piece that cannot be modular. FP by making everything immutable makes your program legos all the way down meaning your smallest primitive can likely be broken down further to reuse in other places and recomposed to form other higher order abstractions that are easier to reason about. In both OOP and procedural programming your designs can never have this level of flexibility due in to modules being tied together by shared mutable state.
Of course there are costs to immutability: both low level costs such as memory management and high level costs such as graph algorithms that require mutability to be effective. There are ways to deal with these issues but they are not trivial. In the end all FP programs must "cheat" in some way and have a small portion of their program actually mutate something.
Overall though, in all my years of programming I have found FP to be the best overall answer to the design problems that most programmers run into. It's by no means a perfect answer but it is the best I've seen and unfortunately not applicable to all domains.
FP offers a better syntax for most of the programs I write, hence it makes the initial effort easier. Especially "compiler like" or "interpreter like" programs more often than not just fall into a pit of success.
But still - my original point remains. I am unable to design a program beforehand. The iteration is just faster with FP.
On one point I disagree: " In both OOP and procedural programming your designs can never have this level of flexibility due in to modules being tied together by shared mutable state."
There is nothing that stops one from writing most OO or procedural programs using immutable style. In fact, this style makes those programs better as well. Just try it. Never mutate an object. Each method, if they must mutate something, then let them return a new object instead.
This style is not applicable everywhere, and due to lack of garbage collected immutable datastructures in the C++ basic library, for example, the area where immutable style can be used is smaller than in a FP language.
And you can't use it in those cases naturally where you actually need to mutate existing storage. But, say, an array of 10 elements? Immutable! Most strings smaller than n * 1000 chars? Immutable! Etc.
>On one point I disagree: " In both OOP and procedural programming your designs can never have this level of flexibility due in to modules being tied together by shared mutable state."
When I define OOP I define it as mutable state. The main reason is because there's a equivalence when you do "immutable OOP"
object.verb(parameter)
verb(object, parameter)
The difference is (mostly) syntactic sugar and it won't change the structure of your programs overall.
That being said:
object.setter()
In fact if you do regular procedural C-style programming with immutable variables your code also becomes isomorphic to FP as assignment becomes equivalent to just creating macros for substitution in an otherwise functional expression.
immutable procedural
def add(x, y):
doublex = x * 2
doubley = y * 2
return doubley + doublex
def add(x, y):
return y * 2 + x * 2
add x y = let doublex = x * 2,
doubley = y * 2
in doubley + doublex
add x y = (y * 2) + (x * 2)
It's all semantics either way and most people do a bit of a hybrid style of programming without ever thinking about what are the real differences so it's not too important.
The thing that's sort of bad about OOP is that it sort of promotes a style of programming where subroutines modify external state that's scoped. You tend to get several subroutines that modify some member variable and this is what prevents you from ever reusing those methods outside of that shared state. <= This is in fact the primary area of "bad design" that most people encounter when doing OOP programming... shared state glues all the lego bricks together making your code inflexible to counter the inevitable changes and flaws that you can never anticipate. The other issue is people never realize that this is what's wrong with their program. They blame their initial design as incorrect when really it analogous to saying that their initial lego project was incorrect and they should have glued the bricks together a different way. The primary key to fixing this design problem is to NOT glue your bricks together at all!
While even though you're capable of the above antics in procedural programming... in procedural programming most programmers tend to keep the mutations scoped to within the boundaries of the function definition hence keeping the function reusable. The downside of this is that if you have shared state within the scope of your function it becomes harder to decompose your function into smaller functions because shared state glues all your internal instructions together.
It's easy to see this face in functional reduce. Higher order functions like reduce allow you to break out the function that actually reduces a list while a for loop with a mutating accumulator can not be broken into further smaller functions.
compare the two below:
loop decomposed into two reusable functions (reduce and add):
add = (acc, x) => x + acc
m = reduce(add, [1,2,3])
m => 6
m = [1,2,3]
acc = 0
for(int i = 0; i < m.length; i++){
acc += m[i]
}
acc => 6"if you're doing OOP your code will have methods and "setters" that mutate or set internal state"
I don't think there is nothing in OOP that "forces" you to explicitly mutate state. People just happen to do it that way, even if there was no need for that.
I.e. instead of mutating an instance of class Foo
void Foo.set(Some bar)
There are several patterns that make instance of Foo immutable. As an example:
1. Use just 'Factory' pattern to build state and disregard mutation altogether FooFactory fact; fact.AddBar(Bar bar); Foo foo = fact.build();
This may appear as mutating (the factory) but the point is the mutations are located at the factory, which is expceted to have a limited scope, and the entity with larger scope (Foo) is immutable wihtout setters.
2. If there is need to modify existing state, instead of mutating the instance, return a new instance with the value modified. So instead of
void foo.Set(Bar bar)
Use method that creates a copy of foo, modifies state, and then returns a new instance of Foo
Foo foo.Modify(Bar bar)
Just removing mutability actually goes long way in making programs more legible akin to functional programs.
I agree functional style is often the best. Unfortunately we just don't have a functional language that could replace C++.
I never said it forces you to do this. Please read my post carefully.
Let me repeat what I wrote. I'm saying that FP and OOP have blurry definitions that people have an intuition about but have not formally defined. Immutable OOP is can be called FP and vice versa. What is the point of having two names for the same style of programming? There is no point that's why you need to focus in on the actual differences. What can you do in OOP that absolutely makes it pure OOP that you cannot call it FP?
That differentiator is setters and mutators. If you use setters and mutators you are doing OOP exclusively and you are NOT doing FP. My response to your post is mostly talking about this semantic issue and why you need to include mutation in your definition of OOP. Otherwise if you don't than I can say all your descriptions of patterns to me are basically FP. You're following the principles of FP and disguising it as OOP and confusion goes in circles.
Please reread my post, I am aware of OOP and it's patterns so there's no need to explain the Factory pattern to me. I'm also in agreement with you like I said.
I am talking about something different: semantics and proper definitions, you likely just glossed over what I wrote, that's why your response is so off topic.
What about Lens.Setter? (http://hackage.haskell.org/package/lens-4.19.2/docs/Control-... )
It is far from obvious, TCP has it's problems over fast and relatively reliable networks. For a random example see [1]
[1] https://blog.ipspace.net/2019/06/do-packet-drops-matter-for-...
In terms of display technologies, we have DisplayPDF from Apple and Wayland on the Linux side.
You take huge risks by just throwing out everything at once. You want a modular system anyway, so run your revolution one module at a time. People don't notice your little revolutions, but that's kind of the point.
Isn't that port required if users want keyboards with true N-key rollover?
Wow, I really had no idea. That's really frustrating...
Any way to fix this? Maybe we can somehow hack the keyboards. They have an USB controller with firmware on it, right?
Hack? Nah. Engineer? Easily.
But the other commenter who noted that it was a BIOS limitation was right - it's not a Windows thing.
Strangely enough, the most recent motherboard I bought (X570-based) has a PS/2 port for the first time in years. No idea why they seem to be making a comeback, but it is kind of nice to be able to directly plug my old Model M in again.
It makes me smile a little to think we've entered the era where 'old' tech is making a comeback in niche circles due to its own merits! I remember the keyjamming detection tool my cousin and I had to use to figure out how we could both play Star Control on the same keyboard. Good times.
I first started running BeOS on my PowerPC Mac clone, back when those were a thing. There was a 1.44MB floppy disk circulating which contained pretty much the full OS, along with a web browser and various utilitied and demo applications.
Inside 1.44MB. It was phenomenal.
Compared to MacOS on the same machine, raw computational benchmarks were about 40% faster, and perceptually, the gains were even better than that, with essentially zero UI lag.
So, starting from scratch can have a lot of benefits, and you don't even need to throw out that much legacy.
My ethernet driver for BeOS was terrible. If I left BeOS running overnight, most of the time I'd awake to a little popup saying something to the effect of "The ethernet driver for your 3c509 has crashed. Click OK to restart the driver." Thank goodness for userspace drivers.
I'm a bit surprised that the iso9660 and UDF drivers are still in kernelspace on Linux, since I can't think of a modern use case where performance of CD/DVD is relevant. Around 2004, I had a corrupted CD-R backup that would kernel panic OSX, Linux, and Win2k3 x64. Unfortunately, there was sensitive financial data, so I wasn't about to submit the image as a repro.
Check out Urbit.
Maybe I'm just pessimistic but I suspect the opposite would occur. It would be buggier, slower and more expensive once you started trying to operate at any kind of scale. The reason being that hidden within all the accumulated layers of cruft are a million fixes for specific security, reliability and performance issues discovered through real world usage.
That's a pity. Wouldn't it be nice if we somehow could separate the cruft from the craft?
What if some computational deity sifted through our collective codebase and distilled the essence, the minimal, purest kernel? Such minimangel's task would be daunting and probably useless, since the moment we'd throw some new use cases and requirements, NIH and patents, POCs and MVPs and we're back to the simmering mess in no time.
So lets call it detail instead. You cannot separate detail from the craft.
Both are "craft", but only the latter is "necessary" and would thus survive the "total rewrite" posited in this "thought experiment".
For example, the x86 is fully of crap; layer upon layer of smarts have been added to deal with design flaws that it was impossible to fix without breaking backward compatibility.
Backward compatibility was practically important, because of network effect (and indeed competitors lose the battle because they were not compatible with x86, or even with their past selves). This practical constrain caused smart people to build smart tricks on top of that foundation.
Sure, it required a lot of smarts to do etc etc but how'd you call it when you end up tunnelling a SCSI command inside an ATA packet wrapped in another SCSI command?
It most certainly is not. It's a macOS and Linux userspace application, no more no less[1].
How on earth do you consider that totally separate from any legacy system?
Only a handful of people would rather use something like Urbit than established systems.
> Eventually, one could write a native hardware kernel
When it does, you can call it an OS. For now, it's a user space application.
All puff. The amateurs over at /r/osdev are much closer to running directly on hypervisors or bare metal than Urbit will ever be.
The other difference is that Android has millions of users, Urbit, not so much.
Sounds like the dream of the "lisp machine". Is it more viable than that?
Identities aren't limited as anyone can create a comet, an identity without a parent (self-signed identity). There is a hierarchy of limited identities which serve as a routing network to propagate software updates and network packets. Since in reality you need to choose some computer to receive software updates from and send network packets to. Comets could communicate without the galaxy/star/planet hierarchy but they would have to choose some other way to route packets (DHT or something).
Urbit can function without Ethereum. AFAIK galaxies (super nodes/identities) participate in Ethereum as a consensus mechanism voluntarily. Nothing is stopping them from changing that.
I don't see it disrupting IP/DNS with cryptographic identities. I'd argue that Kademlia DHT does that in a more significant way.
Not really sure what Urbit does uniquely in that regard really.
I do crave some one-time use generated address that maps to a DHT/Kademlia cluster to provide deterministic privacy against p2p networks that doesn't depend on BGP autonomous centralized entities.
Know of anything like that out of curiosity? Ha.
DHTs do not have a solution to Sybil attacks. In reality, they depend on super nodes. That’s what Urbit’s spanning tree (galaxies/stars/planets) provides, a system of reliable routing. Nothing stops Urbit nodes from using a DHT to communicate, as the network protocol is addressed by identity.
It's not "Ethereum is just..."
Urbit is sacrificing accessibility by adding complexity which Ethereum is, on top of the reputation of what cryptocurrency is, while also additionally requiring the complexity of wallets and ERC-21 (or w/e it is these days) to prove you have address space.
That's bs in my opinion. It should be completely automated like Ygg does it and allow any peer to participate and connect and discover routing deterministically and dynamically.
I hear Urbit can switch at any time, yeah, easier said than done when you've built a lot of expectations on a significant piece of the stack including the wallet and auth parts which are pretty integral. Then shifting the conceptual model? Not likely.
It's not "one time use", but I believe BrightID[1] might be of interest to you. It allows applications to verify that you're a real person without looking into all your metadata and such. And it's not tied directly to your finances, etc like some other ID solutions are.
Potentially it is better to purchase an Urbit ID directly, rather than indirectly purchasing Apple ID through buying their hardware, or a Google/Facebook ID by donating your data.
Nevertheless, despite being presented as a free and open system, it seems like Urbit would centralise power with those selling Urbit IDs to an extent that Google, Apple, Facebook, etc have not yet achieved.
https://sites.google.com/site/dicknewsite/home/computing/byt...
Very cool and groundbreaking technology!
NOTE: Discussed previously on HN:
https://news.ycombinator.com/item?id=9802379
https://news.ycombinator.com/item?id=9806607
When we started moving to cell phones, you could still call a landline phone from one. When we created web browsers, they could hit gopher or ftp URLs. When Stroustrup created C++, he let C code freely interoperate, which let people migrate at their own pace, or even flip back and forth. When Windows was created, it let DOS programs run. When IBM introduces a new mainframe, they always have a way to run programs from the previous generation (back to the 1960s, at a minimum). In all of these cases, interoperability with the old system was essential for the growth of users for the new system.
How many computer users are there now? Three billion? Break backward compatibility and interoperability, and you lock half the planet out - the half that uses computers. And the other half... if they decide to use a computer, are they going to use what everyone else uses, or are they going to decide that your completely incompatible new thing is the right answer? Even if (in some platonic sense) your new thing is the right answer, how are they going to know that?
So, like I said... zero users. 100% user free.
ML solution - many restarts, add momentum and in the end maybe all local maxima are equally good after all.
Starting from scratch is actually feasible on the software side though. The OSDev wiki has many examples. The most recent one I know is Serenity. Still a monumental task. It's probably a lot of fun if you have the time and motivation to stick with it. You can actually throw POSIX in the trash and create your own abstractions. Hopefully people aren't reinventing signals...
I think Linux is the best option for those who want to create something from scratch. The Linux kernel is unique in that it is completely separate from user space. There is a stable, documented kernel interface in the form of system calls:
https://man7.org/linux/man-pages/man2/syscall.2.html
https://man7.org/linux/man-pages/man2/syscalls.2.html
https://www.kernel.org/doc/Documentation/ABI/stable/syscalls
https://www.kernel.org/doc/Documentation/ABI/stable/vdso
So people can actually do things like trash all of GNU and come up with something entirely new. It's possible to rewrite the entire Linux user space in Rust or Lisp or whatever. It doesn't have to be POSIX compliant.
The kernel even has this amazing header which lets people build freestanding Linux programs:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
> This file is designed to be used as a libc alternative for minimal programs with very limited requirements. It consists of a small number of syscall and type definitions, and the minimal startup code needed to call main(). All syscalls are declared as static functions so that they can be optimized away by the compiler when not used.
Yeah, it's an awesome header! It comes straight from the kernel developers too. They use it for their own tools, apparently. It might be missing some of the newer or niche system calls but it has generic mechanisms which can be used to access everything.
I found it during my research for my own Linux system calls library project:
https://github.com/matheusmoreira/liblinux
There's some additional details implemented by my project such as process start up functions which handle argument, environment and auxiliary vectors. I don't see the need to maintain it anymore though since nolibc.h is so amazing and practical.
I even asked Greg Kroah-Hartman about nolibc.h on Reddit:
https://old.reddit.com/r/linux/comments/fx5e4v/im_greg_kroah...
But really, the kernel is not where the innovation potential is. The way it works is really more or less decided by the way the hardware works. That's why the only real "novel" idea in the kernel space is microkernels, which date back decades.
Worth noting that the microkernel revolution kind of happened on Android, which is a re-think-computing-from-scratch kind of project. The drivers are all moved to userspace in Android, using their own IPC mechanism. The Linux kernel is left with less to do.
Is it even possible for one person to design a basic operating system?
https://wiki.osdev.org/Expanded_Main_Page
It's in some way easier today than in the past. VMs really make testing much easier. On the other hand, the hardware has become more complex compared to some years ago when you could assume that all you needed was a little bit of assembly code to initialize the 32-bit mode of the x86 CPU and talk to the IDE interface.
It's been a while since I seriously looked into IPFS, but this is what I remember about it.
The iPad is probably the biggest such attempt to do most of those things. :)
http://web.archive.org/web/20081120092935/http://www.memetec...
Comment is funny in assuming ZFS is objectively better than NTFS or APFS or FAT16.
"From scratch" is a loose definition. And there will necessary be reinventing the wheel.
Making the new wheel incompatible on purpose with the old ones is wasteful. For one thing, you are correct. You don't build a car on a carriage framework. But the principles are the same and there are some technologies that will be reused: bushings for example. What should we do about them?
I think in general doing a grass roots, ground up, all encompassing design is inferior to a more battle tested natural evolution based strategy where you build on top of each other.
Might be wrong, but that's my gut feel. I'm sure there some good examples of the two strategies and how they played out?
Like imagine cars / roads were invented today do you thing they would have all have this same ubiquitous elongated design, with the grill in front and two headlights in the side, or maybe cars would be completely round maybe they would be made generally with standup room, one big head light across the bottom etc.
While some of these design decisions are practical, I believe a lot would be different if we would reimagine it from the bottom up. The reason - for instance - cars cannot be wider is because the wouldn't fit on today's roads roads. Existing safety regulations also prevent certain design possibilities.
Have you also though about how we see 3 holes on a face (2 eyes and 1 mouth, ignoring the downward facing holes of the nostrils) as normal. Just add one more and it’s horror. We take these things granted and then slight changes to it is completely terrifying.
I also wonder - if we rewind evolutionary time and restart with slightly different initial conditions, not sure what species including humans would even exist in the same form. It would likely be like that game Spore.
But I think this would be impossible to cut the cord completely, because a computer is basically a communication system (internally and networked) and by Conway's law groups zero in on comms systems that reflect their own dynamics, so as a civilizations we've built devices and networks that have zeroed in on our own internal dynamics. Therefore as a member of this civilization, you could not create something different. You'd need to go hang with some folks completely different until you absorbed that, then make it to reflect their dynamics. Uncontacted Amazon tribes? Dolphins? Elephants? Plants?
I think that's already possible today - the Legion programming system claims to do exactly that (among other things). I have absolutely no experience with it though so I might be completely wrong.
(https://legion.stanford.edu/)
> By making the Legion programming system aware of the structure of program data, it can automate many of the tedious tasks programmers currently face, including correctly extracting task- and data-level parallelism and moving data around complex memory hierarchies.
Anyway, smartphones / tablets have made us rethink hardware, its developments have led to more compact laptops as well, and the push to more compact laptops have caused their manufacturers (mostly thinking of Apple throughout this comment btw) to eschew legacy systems - disk drives, USB ports, even 3.5mm jacks all went out the window.
But that is exactly what you're proposing here; what did you think when Apple got rid of a lot of that legacy? Personally I have mixed feelings; I do like USB-C. I didn't like Lightning because it was nonstandard, but it was an improvement over their broad connectors and USB-C wasn't a thing yet. I can see why they're pushing to wireless connections for audio and input.
Anyway final point, despite the cut in legacy connectors and the like, Apple's hardware hasn't gotten cheaper.
Arguably, using an existing OS as a base was kind of the only way to get these products done in a reasonable timeframe. They run complex and powerful software and writing that stack alone is hugely demanding. Rewriting the OS would easily have lost the market to the competition because of cost and time overruns.
"Throw out the old" happens in local pieces of the stack all the time. AMD removed a lot of cruft from the Intel ISA when they designed AMD64, Wayland removes a lot of complexity from the display protocol stack, and every I/O port before USB was designed to be incompatible with existing ports.
I feel that what you are describing will look like the SBC situation in the ARM world: the processor instruction set may be identical, but every vendor uses a slightly different incompatible way of connecting and designing the surrounding chipset, which results in a myriad of almost-identical drivers and subtle bugs that are impossible to fix, because the cost/benefit ratio would be prohibitively high.
Standardization isn't just for backwards compatibility, nor does it mandate it. But it does allow for reuse of existing components in an interoperable way. Imagine if every application came as a unikernel microservice instead of an OS framework library: there would be no UI consistency, copy-pasting between different applications would be hard, and you would have no OS-level update facility -- every application would have its own set of vulnerabilities.
Without AMD64 Itanium would have prevailed.
As far as I know, currently there are no "good" real time operating systems available. There are some ancient, crufty ones... and some modern soft-real-time operating systems, but that's it. This would be a fun exercise for someone wanting to write something uniquely useful in Rust, for example.
It might make sense to write a pure web browser engine designed for embedded contexts. Think infotainment systems where the web content being served is fully controlled. This would be an opportunity to write something like a HTML5-only engine with UTF8 only, TLS 1.3 only, HTTP 3 only, etc...
Relational database engines need a massive rethink. All of the current popular ones are 20+ years old, and based on 50+ year old architectures. Why do schema operations take time? Why does index rebuilds lock tables? Why are there column size limits? Why is SQL injection still a thing? Why, why, why... because legacy, that's why. Because hard-coding, that's why. Because 1980s C-style programming with fixed-size buffers, that's why. All of this could be just washed away with a rewrite using Rust, Modern C++, and some fresh ideas.
I think the networking layer should be built off of http://PJON-technologies.com - it's perfect for standardizing the next layer of networking and without depending on any ISP or centralized authority that also has support for multiple "packet/connection" protocols (LoraWAN, Light, Ethernet, and more).
I am going through a history lesson right now on studying older OS's and why they didn't take off while also getting my feet wet with Forth and lower-level hardware experiments. I still have no idea how video truly works, that's something that's been bugging me from a first principles perspective and I want to understand that more intuitively. Something I keep asking myself is: "How do I poke at the video card and make it display stuff without having to use a OS level API that wraps openGL or similar?" - I know some will be shocked at that question and some may go "woah, actually I don't know that" - we're in an interesting generational leap with where knowledge has been in the zeitgeist of computation and networks.
The OG's are in a particular precious bucket where they've done their part and not that active or have been yelling the current stack is wrong but it's hard to find their voices. Then you have the hackers and hardware folk who learned a lot pre-internet that may or may not be active on the typical net's hanging out only in Plan 9 esoteric rooms saying how good the internet was before marketing took over, and then the dot com boom generation which either knows the earlier internet or thinks the internet is only social media and search engines.
I want to make the internet feel adventurous and fun again like the 90's. I want it to be focused on individuals and not organizations. It was exciting because you connected to people, today you don't do that anymore - you interface with some centralized entity that exposes you to products. I have more to say here that is a lot more nuanced but you get my gist.
Urbit is doing something similar to what you're saying, however I personally don't like their networking model and a few other decisions that just feel contrived to me. Plus I want to get my feet wet and understand the layers myself from a first principles perspective so I can add to it as I am imagining it.
Sounds like a new dawn of innovation is bubbling.
My previous comment on a similar tone/opportunity from yesterday: https://news.ycombinator.com/item?id=24467534
Why must bytes have 8 bits, why do we count time as seconds since 1970, why must text be encoded as unicode code points, etc...
There is now such strong external pressure on projects to conform to these table stakes that I think the only thing that will overturn these decisions at this point is the singularity.
But stuff will evolve, people will want to innovate. So they make new hardware, and they make new libraries because lets face it, chances you get everything right the first time is slim to none.
And after a few years you're back to having backwards compatibility issues, and some years after that you're starting to feel the mismatch between hardware and software again etc.
As for cheaper, consider this. You can get an ATX motherboard with lots of functionality most people won't use, for like $50 or so. In low quantities just the PCB alone, just empty tracks with no components would be much more than that.
Another partial approach would be this: imagine you had a completely new console which had a single programming language, all tools needed to develop integrated, dumb simple, and you could draw on the screen easily, manipulate the audio buffers easily, and had trivial access to button inputs. Even without networking, I bet we would see amazing things happen. A closed, small, understandable and yet practical and performant system? The dream of every programmer. I know some people already think we have libraries that do this, but they can't provide such a platform.
In both cases, for different reasons, and in different contexts, the projects set out to reinvent computing from the ground up. The Newton failed in ways that make it a punchline, but the punchline obscures useful things about how it succeeded and how it failed.
Clean Slate seems to have morphed into another research program called CHERI (http://www.csl.sri.com/users/neumann/20191213-ctsrd-ftr-fina...), but it hasn't taken the world by storm, either.
Both projects embodied some fairly radical rethinking of how computing should work. Both were fun and inspiring to work on--among the best things I've done in my career. Neither has conquered the world, though some of Newton's novel features have become commonplace, at least in some form.
On the one hand, the fate of these projects is most likely the fate of any similar attempt to reinvent computing. The scale of the existing computing ecosystem is planetary. No small group of visionaries can exert the force needed to move the planet, and no group big enough to move the planet can be cohesive enough to embody a coherent vision.
On the other hand, I think it's worthwhile to invest in pipe dreams like these. They sometimes invent compelling new things that go on to make positive contributions.
They're also instructive. They teach you what is possible when you ignore inconvenient realities. Smart people given a green field and an inspiring vision can invent some truly wonderful things.
They also teach you what is not possible. You aren't going to simply wipe away the existing infrastructure and replace it wholesale. Its gravitational pull is inexorable. At some stage you have to come to terms with what has gone before, unless you're content for your effort to become a footnote.
Both things are useful things to learn: yes, you can do something novel and inspiring, and that's well worth doing for its own sake. No, you can't, simply through the charisma of a beautiful idea, undo all that has gone before.
Nor, if you could, would that necessarily be a good thing. Finding workable compromises with your surroundings is, after all, a constructive endeavor.
So between spending all that (partially duplicated) effort to rethink everything and the fact that the end result would have little buy in due to the high threshold of effort involved with adopting and using it, this is rarely a tempting proposition for many. Either to develop, or to use.
Often it comes from a sequence of these evolution->revolution chains. When that happens the initial execution of the revolutionary idea is usually buggy and incomplete, but works well enough to demonstrate the idea. Other people then evolve that idea further.
Was that because of the Newton project, or it happened independently?
The problem with this question is that the answers are fuzzy. Newton had a lot of features that are everywhere now, but that were not when it was being developed. Of the features that have become widespread, it's not perfectly clear which ones have Newton ancestry, which share common ancestry with Newton, and which are mostly independent but possibly influenced to some degree by Newton.
There were a lot of ideas swirling around in the late 80s and the early 90s, and a lot of smart people trying them out in different ways. Some of Apple's best people worked on Newton, and afterward went on to work in other places, taking with them their intelligence and creativity and things they learned working on Newton. It's hard to be sure what they did later, or who they influenced with those ideas.
Take Javascript, for example. It's pretty similar to Newtonscript in several ways. Is that because Brendan Eich knew about Newtonscript and was influenced? Or is it because Brendan Eich was influenced by some of the same things that influenced Newtonscript's creator, Walter Smith? Things like Scheme and Self, for example, and like the idea of using a syntax chosen to seem friendly to C (or Java) programmers. Someone who knows Brendan Eich could ask him, or Walter might know something about it; he often comments here.
Newton had a bunch of features that were wild in 1992, and aren't as wild now. Features like transparent wireless network roaming, seamless migration of data between ephemeral and persistent storage, a purely gestural interface built on machine learning, and a simple knowledge-based help system. It was almost small enough to fit in a pocket--but not quite. I think that's one of the major things that worked against it in the market: it wasn't small enough for a pocket, and it wasn't big enough to have a nice screen. It was exactly in the awkward middle.
Its handwriting instantly became a joke, but it was actually pretty good. Once it was trained, it was actually very good, but one of the things that we learned from Newton was that very good is not good enough in a consumer product. Every small step away from perfection loses you customers.
(Newton's handwriting recognition was unusually good for me, and for the other Newton engineers, because our handwriting training data was built into the firmware. Any of us could make any Newton look nearly flawless because it already knew us.)
Its recognition system was actually more sophisticated than I've allowed: it was in fact several different kinds of recognizers working in parallel, coordinated by a blackboard system. Its ability to recognize drawn shapes and convert them into vector graphics that you could immediately edit in-place was very cool. The fact that you could have all these different recognizers all working together on what appeared to be a single sheet of "paper", doing the right thing, whether it was converting handwriting, recognizing drawings, or responding to command gestures, all interleaved, was even cooler, and I'm not aware of another system that achieves that seamless kind of feeling even now.
The first time I ever saw a freely-roaming networked device, it was in Newton's Bubb Road building in Cupertino in about 1992. It was a Newton prototype PC board ribbon-cabled to a Macintosh SE that was being wheeled around the building on a cart so that the engineers could watch as it negotiated connections with different networks. We all imagined a world where you could have a computer in your pocket and, wherever you went, it would just always have network connectivity. That was crazy talk in 1992.
Newton probably isn't why we have that now; rather, more likely, Newton was one of the earliest manifestations of a dream that lots and lots of people were dreaming, and that someone was eventually bound to get working. Still; 1992. It was science fiction then.
Okay, our present mobile devices are not as seamless as the Newton team imagined, but we do have network connectivity pretty much everywhere. It's so ubiquitous now that people probably don't think it's a big deal, unless they're old enough to remember when we didn't have it.
Thanks for writing.
> influenced to some degree by Newton.
Yes I suppose everyone who worked on Newton brought with them their experiences and knowledge to the next place/project.
Take JPEG for example, Six different companies helped develop it, there are six different patented ideas in the arithmetic encoding system and a slew of papers were influential in it's development over decades. You're really going to come up with better ways to do all of that over again from scratch?
OK maybe you come up with a better file system or kernel architecture, but why does that mean you need a new graphics compression format? You're also piling up all the risks together. Coupling together a huge swath of unrelated concerns arbitrarily means if some of them sink they'll bring all the other stuff down with them.
Why aren't there architects writing down the requirements of operating systems and defining their architecture, and, separated, developers working from these designs?
I also wonder why we see so few new ideas in the OS space. From a user's viewpoint, it seems little has changed since the first Unixes were born.
Also who was saying that architecture is the wrong metaphor for software architects and the good metaphor is city planners? They put some frames and infrastructures but mostly enable the creation.
Where it matters, we use hardware acceleration and very thin layers over that acceleration. For example games.
JPEG have good compression and few hundreds of kilobytes to implement its support (and those kilobytes are battle-tested and probably have little to no exploitable bugs). I just don't understand why would you want to drop it. Modern web adopts new image formats, it's not like you must use JPEG today.
Good idea, and then run legacy apps under an emulator. Each instance created and destroyed after use. That way there will be virtually no chance of malware propagating through the system.
And, of course, in the same vein: https://www.nand2tetris.org/
Some surviving info regarding System 3:
https://www.drdobbs.com/architecture-and-design/oberon-syste...
https://www.semanticscholar.org/paper/Oberon-with-Gadgets-A-...
https://sourceforge.net/p/nativeoberon/wiki/Home/
https://www.semanticscholar.org/paper/Project-Oberon-the-des...
Some surviving info regarding Bluebottle (AOS):
https://os-projects.eu/oberon-system
https://www.linux.org.ru/gallery/screenshots/4163239
Unfortunately the www.ocp.inf.ethz.ch seems to have been moved out of Internet. It had quite some information about Bluebottle, although there are some Github mirrors like this one:
https://github.com/cubranic/oberon-a2
The doc directory has lots of nice info.
The latest version of Active Oberon manual as of 2019:
Oberon => Oberon-2 => Component Pascal
=> Active Oberon
=> Oberon.NET => Zonnon
=> Oberon-07 (multiple iterations until 2016)
Active Oberon provides features for manual memory management (untraced references), async/await (active objects hence the name), lightweight generics, interfaces, exceptions.
About half of the innovations were picked up by other manufacturers within a couple years.
This was done with a programming language. Ada was designed through an iterative sequence of trials for a clean sheet implementation of a development language. It created, or popularized, ideas such as explicit module exports, tying directory and file names to classes, separate "to end of line" comments, and more.
About half of the innovations were picked up by other language vendors within a couple years.
Oberon gets mentioned on HackerNews every couple years. It is hard to say its really a clean sheet.
It would be good if there was a VirtualBox distribution. I looked but I saw nothing that I could use.
Just download the Oberon IDE (there are precompiled versions for Windows, Mac and Linux) and run the OberonSystem project included with the IDE.
Sorry if I don't really understand what this is, but it seems like there's a production-ready hardware and software description (written in 2013?) that is applicable today in 2020?
Edit: Is this meant for academic study? And if so, is a basic newbie description available?
What's more, this is all done with a compiled language using GC at runtime, and with a low memory overhead ie. Oberon can be used as a systems language.
There are several projects moving on from this software-wise, A2:
https://www.research-collection.ethz.ch/bitstream/handle/20....
Also, following on from A2, Composita introduces a component architecture to allow managed memory without GC, and contextless switches (IMHO better than Rust)
http://concurrency.ch/Content/publications/Blaeser_Component...
What could be done instead would be a parallel virtual platform inside the current technology that abstracts the current technology in such a degree that many things become trivially doable.
With enough study and motivation everything should be pretty accessible.
I've used it a bit (almost 20 years ago however), certainly still requires committed dedication, then again, just like anything else.
If you want to go further from scratch... Designing a motherboard wouldn't be too hard, though it probably wouldn't be very good or reliable. Same with a power supply. Designing my own CPU is something I could probably do with several months' worth of effort, as a CompE. But actually making a physical chip of it is another matter entirely. It would be expensive and you'd have to pay a manufacturer to do it. Physically making your own CPU at home is pretty much out of the question, but you could use an FPGA. I have no idea how to go about making RAM or hard drives "from scratch". Same for monitors.
From a circuit board etched by someone else and PCB components purchased online and soldered together by a hobbyist, certainly, without too much difficulty (the package used by the programmable gate array requires a bit of specialty equipment, but is within reach).
One other point about Oberon is that I _believe_ that because the design predates open-source FPGA toolchains, a closed toolchain is still required to convert the Verilog (high-level design describing the processor logic) into a netlist (FPGA configuration), and it hasn't been taped out into a chip, either. So, the book covers the design of a computer end-to-middle - that is, without covering how the block / HDL level design becomes logic gates, and without covering how said gates are then manufactured. This is probably fine - the scope has to end somewhere. The linked NAND-to-Tetris articles cover the other end - from logic gates up to typical computing constructs (adder, registers, shifters, etc.).
For example, take a look at the display module [0] -- this 190-line program contains over 20 instances of constant "128", in lines like those:
sa := base + u0*4 + sy*128; da := base + v0*4 + dy*128;
But instead of writing something like "const LineStride = Width / 8", the code just hardcodes the value all over the place.
[0] https://people.inf.ethz.ch/wirth/ProjectOberon/Sources/Displ...
If you want a different display, they'd prefer you to rewrite it from scratch?
Or they may never have thought about running on a different device. Why should I do the work to do it?
This was not done with the idea of portability, maintainability, or even good engineering practice.
He's not primarily a programmer, but a computer engineer. It wasn't his first computer system, and may not even be his last. The mouse stays the same size, but the computers themselves have shrunk dramatically over the years. Maybe when he turns 90 he'll ship-in-a-bottle build a computer inside his favourite mouse?
Ha wouldn't be shocked. Apparently some mice already have ARM processors inside, why not take it a bit further.
Never mind that you’re introducing the possibility for bugs: the compiler would catch if you type the wrong symbol name, but not if you type 129 accidentally.
And anyone reading or maintaining that code now has several additional needless WTFs they’ll encounter in the course of making sense of it.
But more importantly, by giving it a name the code is more self-documenting. New and old programmers don't have to figure out why 128, or if 128 is right or not in this bit of code.
It can't know that with a named constant.
(Same would be true for any value that's a power of 2. Usually a real speed up.)
What were benefits or breakthroughs of the OS when it was created? I wish the 2013 book was available in a physical copy, I'm not a huge fan of PDFs.
http://toastytech.com/guis/cedar.html
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
About 1h video with some developers from Mesa/Cedar done by Computer History Museum.
As for what breakthrough, this are full stack graphical workstations written in GC enabled systems programming language.
To bring it to modern context, imagine something like Windows being fully written in .NET Native, but in the 80's.
> "The primary goal, to personally obtain first-hand experience, and to reach full understanding of every detail, inherently determined our manpower: two part-time programmers. We tentatively set our time-limit for completion to three years. As it later turned out, this had been a good estimate; programming was begun in early 1986, and a first version of the system was released in the fall of 1988."
I think of Wirth and Gutknecht as demonstrating that one need not be as far out as Terry A. Davis to do small-team end-to-end work. (compare Carver Mead's tall thin person)