I did it mom, I'm on hacker news Joking but this is kind of sureal to see my small handmade project on the front page of hacker news.When I started the project I was kinda at the bottom just dropped of university, and now it's a growing community full of really cool people :)
Congrats for the work and the front-page, though you seem to live in alternative universe. The last time I checked, a project with ~2250 commits, ~30 contributors, a website and dozens of releases is by no means "small".
I honestly love how more people are rolling their own OS's. But it stinks how difficult hardware support is.
I wish there was a nice wrapper dedicated to abstracting hardware support better so developers can focus on the interesting parts instead of arguing with wi-fi cards.
I always thought that was kinda the point of an OS, it differentiates itself based on how it does drivers and hardware management, it wraps it all in neat apis so that developers can focus on making over-engineered resource intensive chat clients.
> the point of an OS, it differentiates itself based on how it does drivers
Not really; also, the freedom to do something "different" in the device driver space is extremely limited: all you can do is decide on the packaging, kernel space vs. userspace and not much more.
I think what GP was getting at is a big part of an OS is resource management (process permissions and isolation) and providing abstract interfaces over hardware (filesystems vs raw block storage).
So beyond the low level drivers that directly interact with hardware, an OS differs in how you ... drive the drivers. What your HAL looks like, and then what the abstractions above that look like.
It's by that definition that e.g. Android is considered a different OS from GNU/Linux. Same kernel, but the hardware is exposed much differently to end-user applications.
> I wish there was a nice wrapper dedicated to abstracting hardware support
The NetBSD kernel has the ability to be built as a library, letting various drivers be used in other ways -- it's called a "rump kernel" [0]. I've never played with it myself but my understanding is that this would be sufficient to provide drivers in one's own kernel, given enough plumbing and shims and such.
(With enough shims one could borrow drivers from any kernel -- see ndiswrapper to use Windows network-card drivers in Linux -- but the rump kernel scaffolding is supposed to make it easier.)
> I wish there was a nice wrapper dedicated to abstracting hardware support better so developers can focus on the interesting parts
The University of Utah had a research project back in the late 1990s which offered exactly that – the OSKit project [0]. A set of libraries for common (at the time) x86 hardware so OS developers and researchers could focus on what was original about their OS instead of writing yet another hard disk or Ethernet driver
Unfortunately, the research project ended circa 2000 and it is dead now. No support for contemporary devices like Wifi and USB. But, if you just want something to run in a VM (QEMU or VirtualBox or whatever) it probably still works.
Today, when I build a custom Linux kernel, and am playing with config vars to decide what is our isn't included in the build, I very much tend to think of it as assembling a kernel from various library pieces.
Linux isn't written with the use case of using bits of it in isolation in mind. Sure, you can do that, but the Linux developers don't have making that easy as a design goal, so it will often be quite hard, and even when it isn't so hard that is just an accident. By contrast, the OSKit developers had as an explicit design goal to make it easy to use bits of their code in isolation from the rest.
Linux gives no API stability guarantees for its internal APIs, only for the system call interface. By contrast, the OSKit developers intended the API of each component to be a stable documented interface. The Linux developers don't want Linux's internal APIs to be stable documented interfaces because that has a cost in that it slows down refactoring, which in turn reduces the various benefits that refactoring can produce (better performance, better maintainability, new features, etc)
> The Linux developers don't want Linux's internal APIs to be stable documented interfaces
It also has the "benefit" of making it extremely difficult to actually distribute stable device drivers that are closed source, or are simply not part of the actively-maintained kernel source tree.
> I wish there was a nice wrapper dedicated to abstracting hardware support
There is NopSys, about 3500 lines of C and 600 lines of assembler for booting, accessing device registers, and responding to interrupts. So you can write the rest of the
OS on top of that. CogNOS is a Smalltalk system written on top of NopSys.
In the earlier days of the x86 PC, the hardware was far more documented, but now a lot of manufacturers are notoriously secretive about it. Nonetheless, standards still exist (HDA,ATA/ATAPI/SATA,OHCI/UHCI/EHCI/XHCI,etc.) and much of the backwards compatibility is still there.
You bring up wi-fi cards and that is definitely one category of hardware with little standardisation/documentation (I suspect due to FCC regulations and such.) Wired ethernet is a bit better --- Realtek and Intel NICs are both quite well-documented, with the latter being more complex. The other difficult one is GPU acceleration (but a VESA framebuffer is usually available, which gets you at least a GUI if not a fast one.)
UEFI sort of handles this, even if the spec is absurdly huge. It contains portions referring to standardized ways of interacting with Wi-Fi cards and other devices, even if not all firmware supports it. I started an OS project[1] a while ago based on it.
Are Linux device drivers not nice enough? Hell, why couldn’t one think, for that matter, of a minimal Linux kernel as some kind of BIOS. Incidentally, we already use it as a hypervisor, so you could probably even include support for the devices you want in the hypervisor itself.
There are projects that load Linux as a UEFI DXE, and coreboot pretty much can be configured to initialize the platform and then hand over to a Linux payload immediately.
Completely agree. Something like Project Treble, but for PC hardware.
Thinking about it, this is what the BIOS was originally for: to provide a bare minimum abstraction to the hardware. I hoped that UEFI would extend this abstraction in a meaningful way, making OS development easier. Instead it has made it even more complex.
The original EFI spec very much did extend that abstraction. You can do a lot in an EFI environment if the hardware plays ball: network, disk, video etc
UEFI, sadly, added support for raw x86 option ROMs, to some extent casting us back into the "old" world.
What touches me the most is how much I like the GUI applications look [0][1]. As a person, who use GNOME Shell DE on daily basis I really miss to see the titlebars condensed with the menu just like VSCode does. It was what I liked in the very last Unity DE and I happy to see this once again. I am also amazed how simple the TextEditor is [2][3][4] and how handy looks your libwidget components [5]. Congratulations!
AIOS! It analyzes your usage of features in your current operating system, and uses Deep Learning to provide you with source code with just those features as efficiently as possible (uses approximate solutions to NP-complete algorithms), scoured from open source projects meeting your specified license requirements. Paid features include finding the fastest + bug free drivers. For substantially more money you can get a machine-generated proof of theoretical correctness of a component, including Deeply Learned bug fixes. (Not to be confused with AIX, which is still handmade, or with AIX11 which uses convolved neural networks run on the hn-x11-complaints BigData-set to write a custom X11 server that is still remoteable but also Modernly Designed)
I just recovered from my basement a fully working IBM Thinkpad R60.
I installed Crunchbag++ as debian based OS and it's working like a charm.
I wanted to use as a development machine. I was able to configure everything but an editor with golang support.
The only 32bit editor I found is Sublime Text 3 and that's it.
Atom and VSCode don't support 32 bit images of their app anymore :(
(and no, I didn't want to waste time compiling the atom version - there is a guide but looks not updated)
Anyway, I will try this OS now! UI looks beautiful.
Instead of trying to shoehorn Linux into Windows, they could have launched another product with some of the ideas here. Then Windows 10 would not be in limbo (in terms of UI and features).
I don't understand why Apple and Microsoft feel stuck to one OS.
If MS were to write a new bespoke OS that requires new everything and maintains no backward compatibility (that's the point of a new OS, isn't it?) and launch it to the world, the amount of people who'd rush out and buy it can be counted on one hand. It could be absolutely revolutionary, but it would lack one major thing:
Momentum.
Look at every OS that's on the market right now. It solves a problem. Right now there are very few people who can't pick an OS off the shelf that will solve their particular problem. Be it an RTOS or a fancy gui that your grandma is comfortable with, the software already exists.
I guess what I'm really trying to say is that unless you can upend the current OS landscape while maintaining compatibilty, then a new OS for the masses doesn't solve a problem. It creates one.
Though in name it's not a new OS, Windows 8, 10 are new experiences for anyone who uses them since Windows 7.
I think you're right about momentum, MS isn't able to come out of it's momentum of the old into the new.
For example, Apple transitions to a new OS with confidence and takes the ecosystem with it in a blink of an eye because they are trying control their momentum instead of being driven by it.
Edit: Windows can maintain backward compatibility with its ecosystem if they did it well, like Apple has done.
> Edit: Windows can maintain backward compatibility with its ecosystem if they did it well, like Apple has done.
Backwards compatibility with the ecosystem, especially the enormous ecosystem of software that doesn't have active maintainers chomping at the bit to test/patch/update with every single OS change, is a HUGE part of why people use Windows.
Apple really doesn't have this. Instead, they have a critical mass of software that is inside their RDF and actively updates to every breaking change they roll out. They have the "luxury" of not having to care if they break random bits of old software* in the process.
(* software that may be niche, may not have large individual user bases, but which might actually not have modern up-to-date drop-in replacements)
That's fair. I don't mean that Windows should be replaced. I mean that Windows should do what Windows is good at.
Trying to introduce Linux into Windows isn't one of these things. Doing a UI refresh is fine but trying to make Windows UI conform to spatial computing isn't going to help it or the ecosystem in the long term.
If you look at their app building documentation, it's extremely disconcerting. This much compatibility overhead isn't helping the ecosystem grow.
BSD, IllumninOS, IBM z/OS did it first in supporting Linux APIs in some form, either by syscall remapping or VMs.
Linux compatibility has become more relevant than POSIX, and the easiest way to achieve it is just to bundle it for the ride.
In Microsoft's case, they want to cater to the market that buys Apple devices, to actually develop GNU/Linux software and couldn't care less about Apple's ecosystem, aren't happy with it, and don't bother to support Linux OEMs.
> BSD, IllumninOS, IBM z/OS did it first in supporting Linux APIs in some form, either by syscall remapping or VMs.
z/OS has only gained support for running Linux binaries quite recently, in z/OS 2.4 (released September 2019), which supports running z/Linux Docker containers (zCX). Prior to that, z/OS had no built-in support for running Linux binaries in any form. Microsoft released WSL1 in August 2016. So z/OS got this feature 3 years after Windows did.
You might be thinking of z/VM or PR/SM, both of which support running z/Linux virtual machines (but neither of which is z/OS); or of z/OS Unix System Services, which offers some degree of source compatibility with Linux (through its implementation of the UNIX 95 standard), but doesn't have any Linux binary compatibility.
> as I remember IBM mainframes have had support for Aix/Linux guests for a while now
IBM VM has supported Linux guests ever since Linux was first ported to IBM mainframes, circa 1999-2000. Indeed, it is quite likely the initial port was done using VM.
IBM offered two versions of AIX on mainframes, AIX/370 in 1998 and AIX/ESA in 1991. However, how much code did these have in common with AIX on RS/6000? In the later case, very little – AIX/ESA is actually a port of the Mach kernel based OSF/1 to IBM mainframes, with little or no code shared with RS/6000 AIX (which contemporary AIX descends from). It actually had more in common with Digital/Compaq/HP's discontinued Tru64 UNIX (which is another OSF/1 derivative) than with AIX on RT-PC / POWER. I get the impression that AIX/370 had little or no code in common with RS/6000 AIX either – it was developed by Locus Computer Corporation – but I don't know enough about it to be sure about that. Neither AIX/370 or AIX/ESA ever saw any great adoption – both were discontinued in the 1990s, they were replaced by MVS OpenEdition (later OS/390 OpenEdition, and now z/OS Unix System Services) and also later on also by Linux.
> Instead of trying to shoehorn Linux into Windows, they could have launched another product with some of the ideas here. Then Windows 10 would not be in limbo (in terms of UI and features).
You have cause and effect the wrong way there: Windows 10 is in limbo precisely because MS have acknowledged that massive new OS rewrites every few years isn't cost effective. Not because Microsoft can't work out how to ship a new OS. There was a press release about how Windows would adopt a different release cycle around the launch time of Win 10.
> I don't understand why Apple and Microsoft feel stuck to one OS.
I don't understand why you think Apple or Microsoft fragmenting their install base would be a good thing for business.
This looks like a lot of progress compared to Redox OS, an OS built in Rust which has about 5 years now. And this one has been around for much less time.
Not sure I buy that explanation. Looking through this repo, the kernel, drivers, and many core libraries seem to be written from scratch with no dependencies. There are some deps for reading images, and other things outside of kernel/driver function, but this seems mostly written from ground up (A rust based OS could bind to a C/C++ png or sound file library in the same way).
Writing an OS is a fiddly task to say the least. It's one thing to be motivated to create an OS regardless of language (such as this), vs let's create one to showcase a language. It's harder to recruit people for the latter frankly, and having written OS and kernel code, it's fiddly work that more people talk about then actually enjoy doing it over the long haul.
Also in defense of Redox, I think it has far different goals, rather than getting something up and running with interactivity quickly. SkiftOS is much more "toy"/fun hacking vibe.
Not to belabor the point, but what OSes are actually written in C++?
Most will avoid using many if any C++ features even if they ostensibly use a C++ compiler, and most OSes I've seen (Linux, Windows, Darwin) have kernels written in explicitly C.
Skift appears (at a very quick glance) to be using more "C++-ish" features than typical, though it's still more "C-ish" than your average C++ code.
> Not to belabor the point, but what OSes are actually written in C++?
IBM i – probably best known under its original name of OS/400, the operating system of the IBM AS/400. Its lowest layer is called LIC (Licensed Internal Code), and is written in C++. In the beginning, AS/400 used a proprietary CISC processor called IMPI (never publicly documented, but its instruction set apparently resembled somewhat that of IBM 370 mainframes, without being compatible with them.) User applications and higher-level OS components were not written in IMPI, but in a virtual machine bytecode called MI. LIC was responsible for translating MI code into IMPI and providing low level OS services. The LIC was written in a secret PL/I dialect (IBM has a few of those) called PL/MP. As part of the CISC-to-RISC translation, the PL/MP code of the LIC was rewritten in C++. The higher levels of the OS, which run inside the MI virtual machine, are written in a variety of languages – C++, PL/MI (another secret PL/I dialect) and Modula 2.
Huh. I didn't know the SLIC was written in C++, that's ... kind of surprising to me, for some reason. Dunno. Doesn't seem in-character with the rest of the OS stack somehow. The whole thing always felt very sheltered, even from other parts of IBM. Lots of esoteric languages and layers, and then there's C++, hah.
My desktop runs a POWER chip and it's amusing that there are still custom operating modes from the RS64 chips in modern POWER, like memory tagging to support the SLIC's translation layer. All disabled on openPOWER hardware, but still...
> Huh. I didn't know the SLIC was written in C++, that's ... kind of surprising to me, for some reason. Dunno. Doesn't seem in-character with the rest of the OS stack somehow. The whole thing always felt very sheltered, even from other parts of IBM. Lots of esoteric languages and layers, and then there's C++, hah
I think the whole thing in some way is less-sheltered (especially from other parts of IBM) than it at first appears. Originally IBM planned to replace the 360/370 mainframe line with a brand new platform called "Future Systems". The idea was killed, but it survived in the form of the System/38. So a lot of the novel technologies in S/38 originally came from the mainframe side of the business, albeit ideas they never actually shipped. Most of the lower-level code of S/38 was written in custom PL/I dialects (PL/MP, PL/MI) – something other parts of IBM were big on (much of z/OS is written in PL/X; some of the mainframe firmware was written in PL.8; the 8100 was written in PL/DS). The CISC processor of the original AS/400 had an instruction set inspired by the 370 mainframe architecture. RPG came from the 1400 series, and was supported on 360/370 as well, albeit never very popular there. And of course, EBCDIC. The developers who originally wrote OS/400 (and System/38 CPF before it) did the development work on VM/CMS, since OS/400 was never self-hosting. So a lot of the bits that went into the AS/400 originally came from other parts of IBM, or were consistent with what other parts of IBM were doing.
As far as C++ goes, I think that was a deliberate decision to try to get away from writing code in secret PL/I dialects and move to an industry standard language. Parts of the OS were written in Modula 2, which was an earlier attempt at doing the same thing, albeit that attempt failed because Modula 2 didn't take off like some people thought it would.
In more recent times, the biggest influence on IBM i has been AIX (with PASE) and Linux (with porting open source software to PASE). But it has drawn influences from various other sources over the year. If you have access to an IBM i box, check out the file /QIBM/include/os2.h, which provides (through the other headers it includes) a tiny subset of the OS/2 APIs. (I get the impression the plan, at one point, was to port a lot more of the OS/2 API to OS/400, but the plan died before they could port any more than a tiny subset of it.)
> My desktop runs a POWER chip and it's amusing that there are still custom operating modes from the RS64 chips in modern POWER, like memory tagging to support the SLIC's translation layer
POWER isn't the only architecture with memory tagging now. SPARC has had it since 2015 (SPARC ADI introduced in M7). ARM has an extension for it, MTE (I don't know if any hardware has shipped with it yet, but QEMU emulates it.)
My understanding is the windows kernel is mostly C, with some highly-restricted C++ portions with most of the C++ runtime-dependent bits carefully avoided. XNU is entirely C except for IOKit AFAIK.
My understanding is a lot of C++'s higher level features require pretty thick runtime support and complicate kernel level code to the point the traditional wisdom I've heard in both the hobby world and linux spheres is "Avoid C++ like the plague" or "use C++ but be careful to avoid using exceptions/RTTI/etc".
It looks like Skift (and Haiku, apparently!) are mostly using the "watered down" C++, mostly for classes and templated generics, which is a good reason to use C++, yes.
