Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Open Source Operating Systems Programming Security Software Unix Linux

Rust-Based Redox OS Devs Slam Linux, Unix, GPL 354

Freshly Exhumed writes: Redox OS, a project on GitHub aimed at creating an alternative OS able to run almost all Linux executables with only minimal modifications, is to feature a pure Rust ecosystem, which they hope will improve correctness and security over other OSes. In their own words, 'Redox isn't afraid of dropping the bad parts of POSIX, while preserving modest Linux API compatibility.' They also level harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others. This is probably the most important tenet of Redox. In the past, bad design choices were made by Linux, Unix, BSD, HURD, and so on. We all make mistakes, that's no secret, but there is no reason to repeat others' mistakes." Not stopping there, Redox documentation contains blunt critiques of Plan 9, the GPL, and other mainstays.
This discussion has been archived. No new comments can be posted.

Rust-Based Redox OS Devs Slam Linux, Unix, GPL

Comments Filter:
  • by Anonymous Coward

    It feels like this

    • by Anonymous Coward on Monday March 21, 2016 @10:15AM (#51743205)

      Jeez, doesn't anybody know how to make a link any more? Standards [].

      • by Big Hairy Ian ( 1155547 ) on Monday March 21, 2016 @10:36AM (#51743393)
        I believe he was enabling you to pick your own linking standard :)
        • by duckintheface ( 710137 ) on Monday March 21, 2016 @02:25PM (#51745723)

          The "freedom" of the MIT license is the freedom to deny others access to source code. ReDox claims that they aren't worried about someone adding proprietary code because it would, by definition, have to be an improvement in order to be successful. Yes, except Windows is successful without being an improvement on Linux. How did that happen? It happens because people become dependent on a particular feature, a particular standard Over time that may become inferior but because it's now proprietary, it can't be improved without violating copyright.

          So why not use GPL? ReDox never really answers that obvious question. If the ReDox folks have a great idea, just implement it in the GPL and then everyone can enjoy that great idea. But what they really want is for many people to donate their code so they can then make a profit off it. And that's why the GPL wins over time.

          Also, note that the attack on the GPL specifically focuses on libraries. But in general Linux libraries are covered under the LGPL and not the GPL. So ReDox is setting up a straw man argument. If libraries are a problem, then compare your license to the LGPL.

  • by Anonymous Coward on Monday March 21, 2016 @10:07AM (#51743117)

    Show me the code first, then start shittalking everybody.

  • So what? (Score:5, Insightful)

    by Desler ( 1608317 ) on Monday March 21, 2016 @10:08AM (#51743125)

    Who cares? It's a toy OS written in a toy language. It'll join the thousands of other pet project OSes that no more than a handful of people will ever use.

    • Re:So what? (Score:5, Funny)

      by Anonymous Coward on Monday March 21, 2016 @10:19AM (#51743241)

      Who cares? It's a toy OS written in a toy language. It'll join the thousands of other pet project OSes that no more than a handful of people will ever use.

      You're right, operating systems are a solved problem. Things are fine right now.

      • Re:So what? (Score:5, Insightful)

        by Desler ( 1608317 ) on Monday March 21, 2016 @10:24AM (#51743287)

        These people fail to realize that 99% of users care about applications not the OS nor the purity level of its code or APIs. A handful of Rust hipsters will jump ship and the rest of the world will go "What's RedoxOS and why should I care?"

        • Re:So what? (Score:4, Insightful)

          by mwvdlee ( 775178 ) on Monday March 21, 2016 @10:49AM (#51743503) Homepage

          I think 99% is an underestimation.
          Unless they can make it trivially easy to migrate, they're dead in the water.
          And even then, they need to offer significant and measurable advantages to justify end-user migration.
          Wake me up when it runs Apache, MySQL and PHP or some other complete web stack.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Over and over again, people say "I'm going to create a new [programming language, OS, whatever] and this time it's going to be done right". And then they create something that is just as buggy and unusable as everything else. It's just buggy and unusable in different ways. Starting over from scratch is rarely a good idea.

        • Re:So what? (Score:4, Funny)

          by Desler ( 1608317 ) on Monday March 21, 2016 @10:35AM (#51743377)

          But this OS runs on 200% more smug than other OSes. Clearly that makes it superior.

        • by jiriw ( 444695 )

          Well, most of the time you are right. And then there was Python.

          Sometimes it works. But there never is an 'easy fix'. If you believe you're doing it better, it still needs a lot of work and convincing to be perceived as being better, let alone actually be better than what there was previously. A quick '0.1' and some documentation is not enough to convince the majority of users to join your band wagon. If you think all the work to get to '1.0' is preferable over fixing what's wrong in the established stuff t

          • by Junta ( 36770 )

            Note that even if you think python is just right, it came about in 1994. It's the same generation roughly as the Linux kernel.

            • Re:So what? (Score:5, Interesting)

              by jiriw ( 444695 ) on Monday March 21, 2016 @11:50AM (#51744125) Homepage

              I'm not saying Python is just right... but its development was started because the, then current, mature programming languages (C and shellscript) didn't support the mix of features Guido van Rossum needed... and a language that had many features he did like (ABC), he 'had a number of gripes about' (mainly it was a PITA to extend) so he started making Python.
              It was a typical case of 'developer not happy with current tools, starts making his own almost from scratch'. I see a lot of parallels with this Redux case, and yes I know Python had 27 years to come where it is today. It's already been very usable for most of that time... version 1.0 was released in 'just' 5 years. Same with Linux, by the way, that was made by Torvalds because he wanted a quick and dirty Unix like OS on his 386 and the Hurd didn't cut it. Neither did Minix, which was 16 bit. It took 4 years there to get to 1.0.

              So... let's see in 5 years, shall we? Maybe Redux will be something interesting. But, as I said, they need to do a lot of work first, and then, maybe, there will be others willing to help out. Making a lot of noise first is probably not going to help them get more 'eyeballs'.

  • Purity is easy (Score:5, Insightful)

    by The-Ixian ( 168184 ) on Monday March 21, 2016 @10:10AM (#51743139)

    When you are just starting out or if the project is relatively small.

    The more adoption you gain, the more the purity is corrupted.

    Enjoy the view from your high horse while it lasts I guess.

    • Re: (Score:3, Interesting)

      by Anonymous Coward

      This. I still remember how Java was advertised as a "simple" language when it first came out. And it was, but as time passed they decided they'd better keep up with the features and language fashions that the competition were rolling out.

    • by Anonymous Coward on Monday March 21, 2016 @10:55AM (#51743583)

      The more adoption you gain, the more the purity is corrupted.

      Enjoy the view from your high horse while it lasts I guess.

      This deserves to transcend the limits of Slashdot and get (Score:6, Insightful).

    • Re:Purity is easy (Score:4, Interesting)

      by Art Challenor ( 2621733 ) on Monday March 21, 2016 @12:21PM (#51744417)
      Eternal moral vigilance, such as that provided by the Vigil [] language, is the only way to keep it that way.
  • Meh (Score:2, Insightful)

    by Anonymous Coward

    It's easy to make something clean early on. Stuff gets ugly when it meats the real world.

    I mean best of luck to them I guess, but I doubt this is the next great Linux killer.

    • Indeed. Anyone can talk big about how, unlike every other project in the same arena, they're doing everything the right way from the ground up and it'll be the best thing ever. Inevitably, somewhere down the line they'll either wind up doing things 'wrong' for the sake of practicality like the others, or continue being 'right' and thus impractical so almost no-one uses it for real world stuff.

      But hey, even if it itself doesn't take off, it might introduce some feature or other that Linux or BSD or Hurd or w

  • In other words ... (Score:4, Insightful)

    by gstoddart ( 321705 ) on Monday March 21, 2016 @10:17AM (#51743227) Homepage

    Redox isn't afraid of dropping the bad parts of POSIX, while preserving modest Linux API compatibility.' They also level harsh criticisms at other OSes, saying "...we will not replicate the mistakes made by others.

    This basically means their special little pony of an OS will be kinda sorta compatible, they will take some "principled" stand and break whatever they choose, and will screech and whine about how the rest of the world is doing it wrong.

    Go ahead, be a bunch of yowling zealots, write an OS nobody will care about ... and sit around being all smug about how awesome the thing you've written is while wondering why nobody is using it.

    If you want to have a manifesto of childishness and stern disapproval, don't expect to get taken seriously.

    I worked with a guy who wouldn't bend on his perceived form of "correctness" ... he usually failed to deliver what was required of him and was an ass to work with, because he couldn't get past being a smug prick to get the job done. Delivering nothing is worse than griping it isn't aesthetically and ideologically perfect.

    So, whatever. Throw your tantrum.

    • get the job done.

      Plenty of IT work is done exactly to that spec, almost like Larry the Cable Guy was the project lead, "Geterdone!"

      And you can see this in all the projects that looked fantastic in concept, but failed to execute on practicality or worse, Security.

      Build me a website they said. Just get it running they said. We'll add security later they said. Just get the job done they said. We'll fix it later they said.

      • get the job done.

        Plenty of IT work is done exactly to that spec, almost like Larry the Cable Guy was the project lead, "Geterdone!"

        It's not just IT but all industry of any kind. A company - or anyone doing business - isn't going to spend more than they have to, and if they do, they'll be undercut by the competition. That's why regulation exists - to set the minimum bar no one is allowed to go below - and why IT is going to get its share as it keeps getting more and more important for the functioning of th

  • by hughbar ( 579555 ) on Monday March 21, 2016 @10:21AM (#51743259) Homepage
    In one of the Jurassic Parks. 'No, you're making a whole load of brand new mistakes'. Sorry to be so down on this, but operating systems are quite complex and the open source ones need a decent community as well.
  • by 110010001000 ( 697113 ) on Monday March 21, 2016 @10:23AM (#51743277) Homepage Journal
    This type of microaggressive behavior SHOULD NOT be tolerated in the Rust community. We should all have safe spaces available to create our own OS, no matter what your views are on POSIX. Who is to say what is "correct" or not?
  • by Bruce Perens ( 3872 ) <> on Monday March 21, 2016 @10:24AM (#51743291) Homepage Journal

    It's impressive that they are out to make both their own kernel and their own runtime. At first glance it looks like a monolithic kernel, someone should page Andy Tannenbaum to harass them, and if it's really monolithic that takes a point from the "not making other people's mistakes" column.

    It takes a lot of computer science smarts to even understand what the mistakes in other operating systems were and how to avoid them. And as others have commented, it's easy to point at other's mistakes when your project is in its infancy, much harder when your project is grown up.

    I'll really be impressed if they don't map graphics cards into user space. Nothing's ever stable once you do that. That's the biggest mistake in the whole industry. But I bet they don't take fixing that one on.

    • I was surprised when I read it was a microkernel as well. My first thought was that it would be very impressive considering they've been working on GNU Hurd for more than 25 years and it is not ready for production.
      • I'm not sure we can take Hurd as an indictment of all microkernels. There have been other successful ones.

        • But my understanding of Hurd is that it is the purest implementation of what Stallman and others deem to be philosophically a true microkernel which is seems to be hard to implement in reality due to the wide hardware support required. At least for PCs. I've only become aware of L4 recently but it seems confined to embedded systems and other uses but not PCs.
          • It is true that microprocessor hardware interfaces have become complicated due to all of the hardware tricks that are done for power management, virtualization, and performance optimizations.

            QNX Neutrino, however, seems to run on modern CPUs while remaining a microkernel. I haven't taken a close look at it.

      • I just spent a bunch of time in the technical details of the Hurd, and this is pretty funny.

        They acknowledge if they had simply chosen an existing kernel (that they almost used) it would have turned out better than it did writing their own.

        Also... OSX. It made it farther than Hurd. ;)

        Hurd isn't intended to ever be "ready for production" so it is silly to measure the time in that way. It was worked on for a few years as a serious project, and it has been continued as a research project. It has known architec

    • Redox is based on a microkernel: [] They seem to be emphasizing a very small number of system calls, and making "everything a URL" (instead of everything a file): [] I'm skeptical this will get very far, but let 'em try!
      • Hi David,

        I didn't take much time, but the first thing I found in there was a disk driver. A real microkernel would have that in user mode. So, maybe it's an incipient microkernel.

      • Everything is a url is stupid. What that means is every single reference to a file is going to have to go through the same security checks as any url. Getting a directory listing should be fun times ... checking it even more so ...
        • Having filesystem drivers take near-arbitrary strings isn't a bad idea. Making them all URLs is too constraining, though, Because the first element of a URL is a transfer protocol rather than any designation of the data source/sink - that comes later which is sort of backwards. Consider, for example, how the ISO model is layered. They probably are thinking of overlaying other things on the transfer protocol. Not so clean, IMO. A real URL has the implication of running on an IP-like network before the first

  • Often our zeal towards such systems will often blind us to the problems. Then you combine nostalgia, with familiarity makes it very easy to ignore problems that are right in your face.

    Many of these designs are almost a half century old, while some of them are still really good, others are just showing its age, linking processes to tape based processing of data. Which makes it hard to train because the style of working isn't the same as with modern computing anymore.

  • by Kjella ( 173770 ) on Monday March 21, 2016 @10:28AM (#51743319) Homepage

    But BSD isn't quite there yet: most importantly, it has a monolithic kernel, written in C. This means that a single buggy driver can crash, hang, or cause damage to the system.

    They're in for a rude awakening when they realize that the wrong bits sent to a piece of hardware can in theory kill it no matter if the OS keeps running.... so you got a desktop with no working graphics, a server with no working NIC and so on. Without an IOMMU you can't even keep any DMA-enabled device from writing stuff all over system memory, unless of course you disable DMA and run all memory access over the CPU which will make performance glacial. Oh and Linux isn't quite monolithic, for example all USB devices have user mode drivers. Just the basic read/write functions are in the kernel.

    • Oh and Linux isn't quite monolithic, for example all USB devices have user mode drivers. Just the basic read/write functions are in the kernel.

      Can the GPU drivers be moved to userspace as well? Windows has done this since Vista, and a GPU driver crash results only in a small notification telling that the driver restarted. Isn't Linux all about these kind of hi-tech features?

      • by LWATCDR ( 28044 )

        I wish more people would take a look at Minix3.
        BSD license.
        Drives run in userspace and can heal.

        It needs a lot of work still. Last time I checked it was only 32bit, single cpu/core, no USB support, and frankly lacking a lot of hardware support.

        • I thought the idea of Minix is to intentionally keep it barebones so that it can be used for education and so that it can be fully understood by single person. It's certainly a cool kernel though.
  • They already made the first big mistake - not writing the entire thing in ASM for utter speed.

    Since they did that, I can safely assume they're clueless, and continue using master-race MenuetOS.

  • by Qbertino ( 265505 ) <> on Monday March 21, 2016 @10:38AM (#51743411)

    Old Kung Fu proverb.

  • gpl is a killer. We can see from Linux that companies just won't touch gpl code, which is why no one every contributes from a company

    • by caseih ( 160668 )

      I can't tell if you are trolling, trying to be funny, or if you are serious. I feel compelled to respond, though, as this sort of FUD has to stop because the last part of your statement, that no one ever contributes from a company is patently untrue with the GPL and Linux.

      Yes companies that don't understand the GPL and just want to take code like they can from BSD or MIT fear the GPL. And from what I can see, companies that fear the GPL are the ones that would like to simply take the free code without any

      • I can't tell if you are trolling, trying to be funny, or if you are serious.

        I'm being facetious. They list the GPL as a problem under the section about why most OSs don't get enough contributors. That's clearly vacuous as Linux gets far more contributors than the OSs with "less restrictive" licenses.

        Even the supre-proprietary companies which seem to fear open source with burning irrationality have caved to the inevitable and accepted both GCC and Linux (and often Android) since they don't have a choice. An

  • by caseih ( 160668 ) on Monday March 21, 2016 @10:45AM (#51743469)

    The GPL may not be appropriate for many projects, and Redux' choice not to use it is understandable (they chose MIT), but for Linux, being a very large, multi-corporation affair, the GPL is not only appropriate, it's made Linux what it is today. The so-called viral nature of the GPL is what protects it from corporate interest, keeps it open, and keeps the playing field level for the various contributors and interested companies while being steadily improved by all interested parties.

    It's true that the modified GPLv2 that the Linux kernel uses has loopholes in it, and has been taken advantage of by some (Tivo!), but overall it's been a good choice.

    Had Linux been BSD, or MIT, I just don't think it would be as big or successful as it has been, and so widely contributed to by many competing companies. The BSD and MIT licenses lend themselves to widespread adoption and use without fear of any copyright repercussion. However nothing in them prevents companies from taking the code they want for their own proprietary purposes, never to release it back to the community for mutual benefit.

    I am not saying Redux should not be MIT -licensed. I'm just saying their criticism of Linux using the GPL is debatable.

    • I respect their right to use any license they want, but I think their choice is inferior.

      If you're just writing something for yourself, your choice of license is a matter of preference. If you want wide adoption, you need to provide an incentive or requirement for improvements to your software to come back to the original project. GNU Public License, Lesser GNU Public License, Eclipse Public License, and Mozilla Public License all provide the requirements. MIT, BSD, and Apache licenses do not.

      • by RR ( 64484 )

        I think it's good that they choose a permissive license for their source code, but their reason for it, Why MIT? [] is just... someone is wrong on the Internet []

        The GPL is upstream-centric, the MIT license is downstream-centric. We happen to prioritize downstream more than upstream, since downstream is what really matters: the userbase, the community, the availability.

        It is the GPL that is downstream-centric and MIT that is upstream-centric. The GPL was designed to ensure that the entire program, source code, and ability to use it, are available to the userbase and community. The MIT license is primarily about avoiding liability, so anybody upstream of the userbase has greater privileges than the community.

        I wish the

    • by Bruce Perens ( 3872 ) <> on Monday March 21, 2016 @03:13PM (#51746189) Homepage Journal

      Say share-and-share-alike. "viral" is pejorative and it's not in our interest to continue its usage.

  • by TheDarkMaster ( 1292526 ) on Monday March 21, 2016 @10:49AM (#51743499)
    Hum... Writing an entire operating system in an immature language made by people who apparently only understand javascript and the "web way" of developing things... What can go wrong?
  • Oh please..... (Score:5, Insightful)

    by mlwmohawk ( 801821 ) on Monday March 21, 2016 @10:50AM (#51743517)

    Unics, Unix, UNIX, unix, posix, bsd, linux, minix, plan9, etc. They all come from the same basic design philosophy, and it is a very good starting point, simple, clean, wonderful.

    Then you want applications to run on it. Then you get performance issues. Then you get security issues. Then you get new types of peripherals. Then you get new types of processors and memory architectures. Then it shrinks to be a raspberry PI, then it grows to be massively parallel and fill a room.

    After all that, tell me again about what mistakes you are not going to make.

  • Heartbleed (Score:4, Insightful)

    by david_thornley ( 598059 ) on Monday March 21, 2016 @10:52AM (#51743529)

    Heartbleed is a really bad example of what's wrong with C as a development language. If the developers had used C's safety features, Heartbleed, while still a bug, would not have been a problem. Substitute "calloc" calls for "malloc" calls and there's no problem.

    Heartbleed is an excellent example of what can go wrong when the developers abandon all thought of safety measures, preferring to make everything run as fast as possible at the expense of safety in security-related software. While there are things wrong with C, Heartbleed wasn't one of them.

  • Mistakes (Score:5, Insightful)

    by wonkey_monkey ( 2592601 ) on Monday March 21, 2016 @10:59AM (#51743617) Homepage

    we will not replicate the mistakes made by others

    Nope, you'll just brand new mistakes of your own!

  • I have little faith that we are going to see another OS other than Linux/Winodws/OSX dominate in general computing. The biggest reason is drivers. It's funny that in one of their blurbs they mention that they like BSD over Linux but they mostly still use Linux. I wonder why? Probably because the driver situation is much more comprehensive on Linux. Redox will suffer from the same problem. Don't color me surprised when in a few years this project is stagnant or dead and the developers are all still usi
  • If I yell enough, people will look at me.

  • by ledow ( 319597 ) on Monday March 21, 2016 @11:13AM (#51743763) Homepage

    The userspace, sure. The kernel? How do you intend to access hardware without using a pointer-type that could (if used incorrectly) crash the kernel? And how are you going to program those drivers etc. BETTER than the Linux people who - if they don't use their pointers correctly - will crash the kernel too.

    The userspace can surely benefit from a complete rewrite, but I'm not at all sure what kind of investment in time it would be to rewrite the vast swathes of existing software to be "Redox" compatible, or what would benefit from it. If you're going to do this for security reasons, you can't have unsafe raw pointers, which Rust supports but again "You're on your own, I hope you manage them properly" is the mantra there.

    But a kernel? Or even a set of drivers? Love to see how you're going to get close to that, even if you just convert the existing code and abstract out the memory references.

  • So, on their flame page of "why we rulez and you dr00lz" page, they have TODO - rewrite this. []

    So, you expect to do a full OS, take over the world, and you can't even finish a c.300 word rant. Sure....

    Besides running on PCs, BSD and Linux are the core of iOS/watchOS/tvOS/macOS and android. We're talking billions of devices here. I'd be interested to know what they call a failure. If you have one of these "failure OS"s in your pocket, you may reconsider your zealotry.

  • I wish I still was of that beautiful age where you think that technological superiority and general betterness means anything in the real world :(

  • by Rutulian ( 171771 ) on Monday March 21, 2016 @11:25AM (#51743877)

    While I generally like the idea of new people coming up with new projects and hacking away, the linked documentation reads like flamebait and doesn't have much in the way of substance. Some of their contentions are rather strange. For example,

    There are numerous other OS's, kernels, whatever that lack for contributors, and are in desperate need of more coders. Many times, this is for a good reason. Failures in management, a lack of money, inspiration, or innovation, or a limited set of applications have all caused projects to dwindle and eventually fail. ...
    Take Linux for example:

    Ok, let me stop you there. Linux is not a perfect project by any means, but you can hardly say that it is mismanaged, uninspired, or lacking in innovation or money. It had 4000 contributors [] over about a 1 year period, and 12,000 over a 10 year period. It runs on everything from embedded systems to big iron mainframes and balances the often conflicting needs pretty well, in my opinion. Of all the things you can say about Linux, it does not lack in number of contributors or vitality of the project.

    Legacy until infinity: Old syscalls stay around forever, drivers for long-unbuyable hardware stay in the kernel as a mandatory part.

    Uh, yes. Because, shocking I know, quite a bit of hardware out there still depends on that code. And anyway, as long as somebody is there to maintain it, who cares if it is old. Admittedly, there is some cruft in the kernel. [] It's an old project, so I think it is natural to expect that. But at the same time there are people working on it and trying to keep the codebase modern.

    While they can be disabled, running them in kernel space is essentially unnecessary, and is, by far, the biggest source of system crashes, security issues, and unexpected bugs.

    I'll need a citation for that one. I won't dispute that old code has occasionally caused bugs and crashes, but the statement is hyperbole. The majority of crashes on Linux distributions have nothing to do with the kernel at all. Of the ones that do, it usually has something to do with the binary blobs used to run graphical hardware, which is certainly not old code.

    Huge codebase: To contribute, you must find a place to fit in to nearly 25 million lines of code, in just the kernel. This is due to Linux's monolithic architecture.

    Hurray, this useless debate continues. I'll tell you what. Show me a working performant microkernel (no, XNU is not a microkernel) and I'll concede you have a point. Until then, it is just useless chatter. As to their point, just because the kernel architecture is monolithic doesn't mean the codebase isn't organized. One can in fact easily work on something like a filesystem without touching the network code, for example. Linux has had separate subsystems maintainers since at least 2003.

    Restrictive license: Linux is licensed under GPL2. More on this in Why MIT?.

    Non-sequitur to say the least. While commonly debated on Slashdot, really doesn't contribute anything useful to the discussion.

    Lack of memory safety: Linux has had numerous issues with memory safety throughout time. C is a fine language, but for such a security critical system, C doesn't fit.

    This is really the only interesting thing they have said, but not a lot of detail on what they mean other than that they think the whole kernel should be reimplemented in Rust. Well, let's see how that goes. Check back in what, 5 years?

    Compared to BSD, Linux is completely frontal-lobe-missing, in every imaginable way. The code base is one big, ugly hack, and the design is bad

    • by naasking ( 94116 ) <[naasking] [at] []> on Monday March 21, 2016 @12:51PM (#51744755) Homepage

      Show me a working performant microkernel (no, XNU is not a microkernel) and I'll concede you have a point. Until then, it is just useless chatter.

      L4 and QNX are working, performant microkernels that have seen plenty of deployment in the real world. Not on the desktop granted, but performant microkernels aren't some mythical unicorn, they're everywhere and have been for over a decade.

  • Theo de Raadt, is that you?

Scientists will study your brain to learn more about your distant cousin, Man.