16 ms·

To people which don't understand the overall decision to create another system, I'll talk about at least one benefit to create a system that is not Linux: make

• ansible 9y ago
  > ... POSIX is not so great as well ... Ugh, tell me about it. Just dealing with a relatively simple situation where you've got signals coming in while reading a pipe is a hassle to get completely correct. I am so there for an operating system API that is relatively simple and sane. Where writing correct programs is, if not the easy path, at least not the hard and obscure path.
  • Viper007Bond 9y ago
    Interestingly PowerShell is petty awesome in that regard. You pass around objects instead of trying to parse strings and things.
    • deleted 9y ago
      [deleted]
    • deleted 9y ago
      [deleted]
    • vardump 9y ago
      PowerShell is not Windows API, win32 is. So your comment makes little sense.
    • reificator 9y ago
      Powershell is just that, a shell. I agree that Powershell itself is pleasant enough to use but that's not what's being discussed.
    • msla 9y ago
      > You pass around objects instead of trying to parse strings and things. That can't be very good for debuggability.
      • pzone 9y ago
        Type checking and calling help methods can be useful for debuggability! If you want to figure out what you're looking at in string format, call its .ToString method.
        • msla 9y ago
          Adding extra complexity just means more to go wrong. Plain text can't really go wrong because anything can use it, anything can edit it, anything can show it. With "objects" I'm betting that Powershell itself never fails.
    • sleepydog 9y ago
      I don't think that's what the parent was complaining about, it was more about handling signals correctly. It's incredibly easy to write buggy signal handlers on a Linux system. The "self-pipe" trick[1], and later, signalfd(2) have made signal handling much easier, but a lot of programs still do it the old way. [1]: http://cr.yp.to/docs/selfpipe.html http://cr.yp.to/docs/selfpipe.html [2]: http://man7.org/linux/man-pages/man2/signalfd.2.html http://man7.org/linux/man-pages/man2/signalfd.2.html
  • deleted 9y ago
    [deleted]
  • derefr 9y ago
    I'd be down for an Erlang-like OS ABI (or, to put that another way, a Windows-GUI OS ABI, but for even non-GUI processes): just message-passing IPC all the way down. OS signals, disk IO, network packets, [capabilities on] allocated memory, [ACL'ed] file handles, etc: all just (possibly zero-copy) messages sitting in your process's inbox. Of course, it's pretty hard to deal with a setup like that from plain C + libc + libpthread code, so OSes shy away from it. But if your OS also has OS-global sandboxed task-thread pools (like macOS's libdispatch)—and people are willing to use languages slightly higher-level than C where tasks built on those thread-pools are exposed as primitives—then it's not out of the question to write rather low-level code (i.e. code without any intermediating virtual-machine abstraction) that interacts with such a system.
    • pavlov 9y ago
      > ... message-passing IPC all the way down Wasn't QNX like that?
      • dfox 9y ago
        QNX IPC mechanism is essentially cross-process function call, ie. message sender is always blocked while waiting for message reply and the server process cannot meaningfully combine waiting for message and some other event. Edit: in essence QNX messages work like syscalls, with the difference that there are multiple "systems" that accept "syscalls". For what it's worth Solaris has quite similar IPC mechanism that is mostly unused.
  • my123 9y ago
    The NT Native API is relatively elegant, especially Alpc (a shame that it's mostly hidden by Win32 tho)
    • vardump 9y ago
      The biggest blunder is that ALPC is not accessible through Win32 at all. ALPC is much more sane than any other IPC Windows got. Sure, you can use ALPC, but only by using undocumented unstable NT API... Sigh.
  • henesy 9y ago
    Plan 9?
• joelthelion 9y ago
  Don't worry, by the time it is complete and mature, it will be complex and full of quirks too. I'm not convinced that even Google has the resources to build something like that successfully. Except perhaps if they target a very specific use case.
  • kev009 9y ago
    What do you make of, for instance, OS X or VxWorks?
    • Alupis 9y ago
      OSX is based on Darwin, which is a Unix (BSD-like) operating system. I'm certain you can find complexities and bloat in there too, if you look.
      • Waterluvian 9y ago
        Of course. And they don't even pretend that's untrue. Every few releases they focus on lowering bloat.
      • kev009 9y ago
        I'm referencing the abilities of F500 companies to sustain OS development. OS X has roots in mach, and some BSD, but to call it either one is trivializing the amount of work that has gone on.
      • shp0ngle 9y ago
        Oh hell yeah OS X has tons of weird quirks and compatibility mindfucks going back to their transition from OS 9 (all those .DS_Store and _filename files for "resource forks") Backwards compatibility is #1 reason for increasing complexity. Apple is sometimes good in cutting away compatibility for the sake of cleaning up, but there are still weird issues poking now and then hell the whole NSEverything is a compatibility thing with NextStep, which is long dead.
        • 9y ago
• agumonkey 9y ago
  how much of linux LoC are drivers and arch versus generic code ?
  • CodeArtisan 9y ago
    Can't tell how many LoC but there is an initiative about producing tiny linux kernel that you can read about here https://www.linux.com/news/event/open-source-summit-na/2017/4/shrinking-linux-kernel-and-file-system-iot https://www.linux.com/news/event/open-source-summit-na/2017/... In the video, it is show that the binary size of "core" linux has barely grown https://youtu.be/ynNLlzOElOU?t=14m45s https://youtu.be/ynNLlzOElOU?t=14m45s
    • agumonkey 9y ago
      Pretty cool. I had no idea about this project, thanks.
• NiveaGeForce 9y ago
  I like this description of Linux https://www.youtube.com/watch?v=rmsIZUuBoQs https://www.youtube.com/watch?v=rmsIZUuBoQs
• hawski 9y ago
  I recognize that Linux and especially GNU are bloated. However the Linux LOC overtime chart is useless at demonstrating it. AFAIK size increase of Linux is mainly caused by drivers. Device support is overall the most important thing OS offers. And it's hard to be small and elegant while supporting everything under the sun, which Linux can't even really achieve. One could say something about epoll instead of kqueue, ALSA instead of OSS or other similar cases. But the size itself doesn't say much. I agree that there is much to be explored yet in OS design. However it needs deep pockets to actually support wide array of hardware. Or a long time. I cheer for Toybox and Oil shell regarding the GNU userland. When I see all the openat(2) and friends family of functions or chmod/fchmod, chdir/fchdir, barbaz/fbarbaz I'm thinking that it all needs a bit of a clean up. Some batching system call would be appreciated as after Meltdown syscalls are more expensive. I personally like and keep my fingers crossed for DragonflyBSD. They are doing things that are innovative while keeping conservative core for the lack of better words. But at the same time DragonflyBSD has minuscule hardware support comparing to Linux.
  • salatschussel 9y ago
    I don't think changing the usage of system calls in the kernel as a reaction to Meltdown is a good workaround to make. This could lead to CPU makers relying on the workaround rather than fixing the issue in their CPU architecture. The other side of the medal is that this increases the motivation to switch to a newer CPU, which generates more waste, and the fact that CPUs running slower need to run longer, and use more energy, both of which is bad for the environment, and costs money.
• jwilk 9y ago
  This is TLPI cover: http://man7.org/tlpi/cover/TLPI-front-cover.png http://man7.org/tlpi/cover/TLPI-front-cover.png I don't know what this thing is, but it doesn't look very appealing.
  • jasonjayr 9y ago
    It's a Fiddlehead fern :) https://en.wikipedia.org/wiki/Fiddlehead_fern https://en.wikipedia.org/wiki/Fiddlehead_fern
  • 52-6F-62 9y ago
    Mind the digression, but it's a Fiddlehead, and they're delicious. https://en.wikipedia.org/wiki/Fiddlehead_fern https://en.wikipedia.org/wiki/Fiddlehead_fern
• hackcasual 9y ago
  Fuchsia is a microkernel architecture, so I think it being "more efficient" generally is not going to be the case. I do think it is valuable to see a microkernel architecture with large scale backing, as it simplifies security and isolation of subprocesses.
  • lallysingh 9y ago
    Or may be better at splitting up work across cores. Less lock/cache contention, better logical separation, etc.
    • bad_user 9y ago
      No, it won’t. This is not the user land you’re talking about and in general the idea that multiple, isolated processes can do better on the same CPU, versus a monolithic process that does shared memory concurrency is ... a myth ;-)
      • lallysingh 9y ago
        For throughput, separate processes on separate cores with loose synchronisation will do better than a monolith. You don't want to share memory, you want to hand it off to different stages of work. Consider showing a webpage. You have a network stack, a graphics driver, and the threads of the actual browser process itself. It's substantially easier to about bottlenecking through one or more locks (for, say an open file table, or path lookup, etc) when the parts of the pipeline are more separated than a monolithic kernel.
        • bad_user 9y ago
          “Handing off” via sharing memory is much more efficient than copying. Lock-free concurrency is also achievable. Again, this isn’t the user land we’re talking about, in the sense that the kernel is expected to be highly optimized. Granted, a multi process architecture does have virtues, like stability and security. But performance is not one of them.
• jpfr 9y ago
  A huge portion of Linux is drivers and support for different processor architectures. Yes, development was chaotic in the nineties and the code showed. But a lot of engineering effort went into making the core really nice. https://unix.stackexchange.com/a/223763 https://unix.stackexchange.com/a/223763 With regards to POSIX, it is amazing how well this API is holding up. There are quite a few implementions from GNU, BSDs, Microsoft (at least partial support in MSVC) and a few others (e.g. musl). So POSIX support is a given on most systems. Why replace it with something that breaks existing code? https://www.musl-libc.org/faq.html https://www.musl-libc.org/faq.html Not to say there is no bloat. But some bloat is the patina that all succesful systems take on over time. Is the bloat small enough to be managed and/or contained? I say yes.
  • derefr 9y ago
    > So POSIX support is a given on most systems. Why replace it with something that breaks existing code? You're not necessarily breaking existing code. Both macOS and Windows are built on non-POSIX primitives that have POSIX compatibility layers. It seems that the conclusion most of industry has reached is that, whether or not POSIX is a useful API for your average piece of software, there are still better base-layer semantics to architect your kernel, IPC mechanisms, etc. in terms of than the POSIX ones. You can always support a POSIX "flavor" or "branded zone" or "compatibility subsystem" or whatever you want to call it, to run other people's code, after you've written all your code against the nicer set of primitives. An potentially-enlightening analogy: POSIX is like OpenGL. Why do people want Vulkan if OpenGL exists? Well, because Vulkan is a more flexible base-layer with better semantics for high-efficiency use-cases. And if you start with Vulkan, the OpenGL APIs can still be implemented (efficiently!) in terms of them; whereas if you start with an OpenGL-based graphics driver, you can't "get to" (efficient) Vulkan support from there. All that aside, though, I would expect that the real argument is: Fuchsia is for ChromeOS. Google are happy to be the sole maintainers of ChromeOS's kernel and all of its system services, so why not rewrite them all to take advantage of better system-primitive semantics? And Google doesn't have to worry about what apps can run on a Fuchsia-based ChromeOS, because the two ways apps currently run on ChromeOS are "as web-apps in Chrome", or "as Linux ELF executables inside a Linux ABI (or now also Android ABI) sandbox." There is no "ChromeOS software" that needs to be ported to Fuchsia, other than Chrome itself, and the container daemon.
• nerraga 9y ago
  Is TLPI available for free now? It's a great book and I hope that people will continue to support both NoStarch and the author.
  • jwilk 9y ago
    I see no evidence of the book becoming free on its homepage: http://man7.org/tlpi/ http://man7.org/tlpi/ https://doc.lagout.org/ https://doc.lagout.org/ looks quite shady, so I guess someone uploaded their copy without copyright holder's permission.
• SlowBro 9y ago
  > Sometimes it's even more simple re-inventing the wheel than understand why a wheel was build a fractal design When I saw your comment I immediately was reminded of Joel on Software: "The single worst strategic mistake that any software company can make is to rewrite the code from scratch."[1] [1] https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
  • reificator 9y ago
    I live by that quote every day, but it's not a silver bullet.
    • z3t4 9y ago
      you usually get it right on the second time. only hope the first dont get too popular.
      • dfox 9y ago
        In my experience the second time leads to architecture astronautics... third time is when you get it right. Althought in OS space one might argue that second generation of time sharing OSes (TOPS-10, ITS, MCP...) got more things right than are right in Unix and such.
        • tandr 9y ago
          I like the term "architecture astronautics". There is probably a joke hiding somewhere in a plain sight about "Plan 9" wrt Unix...
          • dfox 9y ago
            For OS it means that you should pick one abstraction for process state and one abstraction for IO and in fact you can have same abstraction for both. In this view Plan 9 makes sense while modern Unix with files, sockets, AIO, signals, various pthread and IPC primitives and so on does not (not to mention the fact that on every practical POSIX implementation various such mechanisms are emulated in terms of other synchronisation mechanisms)
• msla 9y ago
  "Bloat" is a loaded term. It's meaningless to say "Look at all this code! It's bloated!" when you don't know the reason those lines are there, and comparing two "solutions" is meaningless when they don't solve all the same problems. Mainly, I'm just getting tired of people trying to cut things out of the solution by cutting them out of the problem. Saying that it's possible to solve a problem in a simpler fashion is fine. Saying a problem shouldn't be solved, that nobody should have that problem, so therefore we won't solve it, is not fine if you then turn around and compare your cut-down solution to the full solution.
• mtgx 9y ago
  It's still a shame they wrote something from scratch but they didn't do it in Rust, so they can avoid fixing a ton of bugs over the next 20-30 years.
  • steveklabnik 9y ago
    The kernel was started before Rust 1.0, so I think that was a reasonable decision. Additionally, since it's a microkernel, the kernel is pretty small. That helps, both in the implementation now and if they ever decided to replace it. And future components can be in Rust if they want.
  • klez 9y ago
    Honestly curious: why Rust specifically and not any other "secure" systems language?
    • lambda 9y ago
      Rust specifically because it has the zero-overhead safety properties via the borrow checker. This is something that no other safe language has, as far as I know. They generally either make you deal with a GC if you want safety, or deal with raw pointers and manual memory management if you want low overhead. And the borrow checker, along with move semantics by default and the Send and Sync traits, help with several other aspects of safety as well; the Send and Sync traits encode information on what can safely be moved or shared between threads, and move semantics by default (and checked by the compiler, instead of at runtime as in C++), make it easier to encode state transitions on objects in ways that you can't try to perform operations on an invalid state. But as others point out, Zircon, the Fuchsia kernel, was written before Rust 1.0 was released, and even after Rust 1.0 was released and stable it was still a bit rough to work with for a little while. If you were starting a new project from scratch today, I'd seriously ask why not Rust, though of course there are other reasons why you might not choose it. But given the history, and how new Rust was at the time when this project was started, it makes a lot of sense.
      • greenhouse_gas 9y ago
• iro3939 9y ago
  It’s almost if humans have a habit of making big things and moving on after enough of the voices behind big thing die and we all forget the original reasons Fuschia will become another monolith where the assumptions no longer matter given tech of 2035 or whatever, and something new will happen IMO the better model would be a simple hardware BIOS type thing with a standardized build system embedded that enables completely custom environment builds from whatever source repo people want These big monoliths seemed more valuable in a pre-internet is everywhere world, so they include the kitchen sink too
  • lobster_johnson 9y ago
    Fuchsia is not a monolith in a design sense, though -- it's a microkernel, and the device interface is based on IPC, which means you can keep the kernel clean and simple, and put drivers elsewhere. For comparison, the majority of the Linux source tree is drivers and file systems. The kernel proper is pretty small. But because it's a monolith, it all has to live and evolve together.
    • iro3939 9y ago
      I’m not speaking to the technical implementation I’m talking to the commentary about a dated cultural artifact sucking, championing of new hotness, a new culture that will develop around it and eventually fade as technology changes and the peddlers of the latest and greatest will largely say the same “wtf @ this mess” But downvote reality of human progress that has occurred over and over The opinionated nature of humans is bizarre, given that we keep, in a social way, repeating our dead relatives We can fix the future from a past that won’t live to see it It’s all nonsense for the majority of humans, but this little microcosm called HN has its finger in the pulse of what we’ll need in 2040!
      • deleted 9y ago
        [deleted]
• kraig911 9y ago
  Maybe they've developed fear of FOSS after this oracle debacle and just want to greenfield the whole thing out of fear.
  • chris37879 9y ago
    A lot of people speculate that that's why Flutter was written in Dart instead of Kotlin or something else. Google wanted to use a language they already have a lot of investment in, and for some reason didn't pick Go. Which honestly seems odd to me since Go can be compiled all the way down to binaries already, they had to invent that compiler for dart, but whatever. Dart is super cool and I'm looking forward to using it in Flutter's user space.
    • pjmlp 9y ago
      Dart supports generics, has a good package manager and their devs are open to the history of programming language's design and modern tooling.
      • Jyaif 9y ago
        Go isn't interpreted, making hot-reload impossible.
  • bitmapbrother 9y ago
    I think it's pretty clear why they created Fuchsia: 1. They want a modular microkernel OS with modern capabilities. 2. They want to eventually replace their internal Linux based OS with Fuchsia. 3. Fuchsia, or parts of it, will be the basis for all of their products. 4. They want to control the direction of their own OS.
    • deleted 9y ago
      [deleted]
• kyrra 9y ago
  (the below is my ignorant understand of drivers in Fuschia and linux) It's not just the kernel design, it's the driver design as well. Fuschia has drivers being ELF binaries that hook into Device Manager process[0]. I believe they are developing a standard API for how drivers interact with Fuschia. Linux doesn't really have this today, which means that the driver must be in the kernel tree to have it keep up with the kernel's interface. And with ARM lacking something like a BIOS for phones, each chip that Qualcomm et al make requires a full BSP to get it working. And from what I understand, Linus and others don't want these (relatively) short-lived processors to be checked into mainline linux (plus you have the lag time of that code being available). Android's Project Treble[1] aims to address this some by creating a stable API for hardware makers to use to talk with Linux, but it is not an ideal solution. [0] https://fuchsia.googlesource.com/zircon/+/HEAD/docs/ddk/overview.md https://fuchsia.googlesource.com/zircon/+/HEAD/docs/ddk/over... [1] https://android-developers.googleblog.com/2017/05/here-comes-treble-modular-base-for.html https://android-developers.googleblog.com/2017/05/here-comes...
  • petecox 9y ago
    > Linus and others don't want these (relatively) short-lived processors to be checked into mainline linux I don't think that's true. e.g. 4.17 is accepting code to run Samsung Galaxy S3 (released nearly 5 years ago). It is left to volunteers since most vendors dump a source release to comply with the GPL but themselves don't upstream it to Linus.
    • StillBored 9y ago
      Because it can take 5 years, in which time the product is obsolete. But, the core idea behind SBSA and SBBR is to form a common platform to which the vendors conform their machines so they don't have to keep up-streaming special little drivers for their special little SOCs. Only time will tell if its a success, but a large part of the community has effectively declared that they aren't really going to conform to the ideals of a standard platform. So, the ball keeps rolling and new DT properties keep getting added, and new pieces of core platform IP keep showing up. At this point arm64, despite just being a few years old already looks as crufty as much older architectures with regard to GIC versions, dozens of firmware interfaces, etc due to the lack of a coherent platform/firmware isolation strategy.
• monochromatic 9y ago
  https://en.wikipedia.org/wiki/TempleOS https://en.wikipedia.org/wiki/TempleOS Problem solved!
• harikb 9y ago
  Didn't think I will see a day where Linux-bashing didn't include a comparison to FreeBSD
• andrepd 9y ago
  I honestly don't get what your 3rd reference is complaining about. That software has... more features and is faster (with the tradeoff being code size)?
• phlakaton 9y ago
  This was, more or less, the driving philosophy behind BeOS. Therein lie some lessons for the prospective OS developer to consider. Say what you will about how terrible POSIX is, Be recognized the tremendous value in supporting POSIX: being able to support the mounds and mounds of software written for POSIX. It chose to keep enough POSIX compatibility to make it possible to port many common UNIX shells and utilities over, while Be developers could focus on more interesting things. So where were the problems? One huge problem was drivers, particularly once BeOS broke into the Intel PC space. Its driver interface and model was pretty darn slick, but it was different, and vendors wouldn't support it (take the problems of a Linux developer getting a spec or reference implementation from a vendor and multiply). This cost Be, and its developer and user community, quite a bit of blood, sweat, and tears. Another big problem was networking. Initially, socket FDs were not the same thing as filesystem FDs, which had a huge impact on the difficulty of porting networked software over to BeOS. Eventually, BeOS fixed this problem, as the lack of compatibility was causing major headaches. The lesson: if you are looking to make an OS that will grow quickly, where you will not be forced to reinvent the wheel over and over and over again, compatibility is no small consideration.
  • pjmlp 9y ago
    Android and ChromeOS don't expose POSIX to userspace, it hasn't hurt them.
    • phlakaton 9y ago
      Which points to what ended up happening with BeOS: it became an internet appliance OS, and then the core of a mobile product. These were areas where the hardware and application spaces were quite constrained, and BeOS's competitive advantage in size and performance could be leveraged.
• brianon99 9y ago
  LOC is not a good way to measure the "bloatness" of a software. There is a significant amount of device driver code in linux kernel. With the number of devices exponentially increasing, it is inevitable, but it does not make the kernel more complex. A truck is not more complex than a car. A truck is bigger because it is designed to carry more load.
• ryao 9y ago
  That article by Columbia claims that dbus is not POSIX, yet the communication occurs over a UNIX domain socket. I do not think that is a good example of not using POSIX for IPC. The underlying mechanism that makes it work is part of POSIX. It just extends what is available to provide IPC from user space in a way that people find more convenient.
• littlestymaar 9y ago
  Bloat is what you get when your software has to face the real world. Yes the Linux kernel is bloated, bloated with tons of code responsible for making it work on exotic hardware. Yes x86 is bloated, let's just remove those useless AVX instructions. Yes MS Excel is bloated, who the hell is using all those features [1]?! You can only have two alternatives : either your software is “bloated”, or then it will be replaced by something else, which is more “bloated” and works for more people. Notice than I'm just criticizing the “bloat” argument, I'm just not criticizing Google for creating a new OS from scratch, which can bring a lot on the table, if done properly and includes innovations from the past 30 years, like was done when creating Rust for instance. [1]: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...