Slashdot Mirror


Syllable's Kristian Van Der Vliet Interview

Andreas Louca writes "OSNews.com has a nice interview with Syllable's Project Leader, Kristian Van Der Vliet. Syllable is one of the teams that raised off the ashes of AtheOS. They talk about the future of Syllable and the current status. "

10 of 123 comments (clear)

  1. Commodity Hardware by kalidasa · · Score: 5, Interesting

    The most interesting part to the interview is where he starts talking about the difficulty in coding for modern hardware interfaces; he suggests that as easier-to-code interfaces like PS/2 and the floppy are rplaced with harder-to-code interfaces like USB, the end of the hobby OS may be at hand. As the barrier-to-entry for coding OSes for commodity hardware grows larger, doesn't that suggest that the opportunity for new robust OSes to evolve to compete with the established players (not only Windows, but OS X, the other BSDs, and Linux) may not exist in the future? Is it possible that the evolution of the OS may be choked by the evolution of the hardware?

    1. Re:Commodity Hardware by Anonymous Coward · · Score: 1, Interesting

      The great thing about open source is variety and legacy. OSS remembers its roots and keeps archives. Projects may die out, but it is truly hard (dare I say impossible?) to loose anything of value.

      I think there are many people who believe that if the OSS community wants to make something, nothing will really stop it.

      Looking over /., there is a new, incredibly complex and even (sometimes, yes) meaningless project every other day. I personally believe we are only limited by how we limit ourselves.

      Look at the innovation and complexities OSS has already overcome. It really is amazing - we almost take it for granted. A hobby is something what you wish you could get paid for. That leaves a lot of room open for big projects.

    2. Re:Commodity Hardware by Anonymous Coward · · Score: 2, Interesting

      Where is the fun or learning experience in just taking code from someplace else? I think you misunderstand; a large number of hobby OS's are just that, an opurtunity for a single person to hack on the hardware at a low level and learn how their computer works. Most of them are no more than a kernel with a schedular and allocator that boots from a floppy. This is fairly easy to do because the code required to do it is managable by a single person in a sensible time frame.

      If the hardware becomes more complex, the time required to learn how to use it increases. People just wont bother. Have you even looked at the IA-64 programming manual? EPIC (VLIW) instructions sets are not designed to be written by hand, how the heck can a single person expect to write their own OS using a complex instruction set like that?

      Complexity could just be enough to make enough people not bother, and that would be a massive lose.

    3. Re:Commodity Hardware by Deusy · · Score: 3, Interesting

      If it was only the hardware that was evolving, then yes this would be the case.

      This is unlikely to be the case. Should it get to the point where the hardware is too many and too complicated for everybody to program for, you'll find generic interfaces to the hardware being implemented in generic assembly languages like table assembly.

      Or perhaps firmware will develop further to ease driver creation.

      There are many areas in which layers can develop to keep developing drivers possible for mortals. The industry isn't going to make things too difficult for itself.

      Ever since the computer industry started, each extra level of complexity has seen an extra layer added to keep software creation manageable, and drivers are no exception.

      Whilst Kristian's fears have foundation, there'll be ways around them even if it's as extreme as hobby OSes having to cooperate on driver development.

      --

      Free Gamer - Free games list and commentary

    4. Re:Commodity Hardware by Bunji+X · · Score: 2, Interesting

      New interfaces are always harder to code for, until standardized drivers become available.

      Yes, but as hardware becomes increasingly complex, drivers, libraries and toolkits will be equally more difficult to write. Even more so if you don't have reference material for the hardware you are writing drivers for, as most OS projects don't have today.

      It is not like standardized drivers appear magically for an OS, except a few select ones with critical mass.

      --
      ---
      The combined human population is enough to feed every living tiger for app. 28000 years.
  2. Re:It... by jared_hanson · · Score: 2, Interesting

    Well, I was thinking more along the lines of protected memory and capable of running multiple processes. Your thinking of programs again. People should really learn the distinction between an operating system and the programs that run on top of it.

    --
    -- Fighting mediocrity one bad post at a time.
  3. Re:They used khtml before apple. by powerlinekid · · Score: 2, Interesting

    This isn't offtopic really. People made a big deal about Safari, but ABrowse (my current beast of a project) has been using KHTML since around 98-99. I'm currently working on the update so our render engine can be more compatible.

    --

    can't sleep slashdot will eat me
  4. Re:Sounds cool, but... by the+morgawr · · Score: 2, Interesting
    It seems a lot of people misunderstood what I was saying (and like I said I could be wrong): Syllable needs to have a terminal emulator, a text editor, a web browser, etc. and a bunch of other generic apps which are basically the same as the stuff that's out there with any given linux distro or a BSD. For their kernel they have to have a scheduler, a VM system, drivers, file systems, etc. 99% of this code could be take from something already out there - leaving the developers to focus on what they seem to what to do: making something more useable then the horrible, inconsistant UIs that plauge open source today. It seems from the website that most of this code was rewritten. This wastes effort because instead of improving on a current VM system or driver, they wrote their own. They can use someone else's code and still have their own project, still have fun, and get more work done.

    That said, the goal of the project seems to be to make a more useable system. Unless I misunderstand the plan of attack, I see no reason they couldn't make a UI (and other extenstions) that works with existing OSes instead of reinventing the wheel on everything else. A compleate OS is a huge undertaking, and I wish them the best of luck, but I don't understand why you need a new OS to have a better UI.

    --
    The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
  5. Re:Sounds cool, but... by the+morgawr · · Score: 3, Interesting
    Fair enough, I hope you guys are having fun and do well. I've got some question's if you'd bother to answer them.

    Linux internals are very messy. BSD is a lot cleaner, clean enough that researchers chop it up for use in experimental OSes. Why not start from something that works and has solid hardware support? Was it just more fun to do it from scratch or was there a design reson why reworking an existing system or just using large chunks of code wasn't an option?

    I'm no UI expert but the code for X, KDE, and GNOME isn't pretty (and from a user's stand point, the UI isn't friendly). I'm sure that you guys can do a better job. Most people won't get to enjoy the results of your labor though, because your OS isn't compatible with the vast pool of Free and Open software out there. Asking people to take such a huge jump is hard (but not imposible). Why not make a UI to work on top of what's already there? What do current systems not support or do, that you felt compelled to rewrite? What advantages does your design offer over current systems? Can you still display remotely?

    --
    The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
  6. Re:How do you maintain order and good design? by Vanders · · Score: 2, Interesting

    I understand what you're saying. Yes, over the last few releases bugs have crept in and have been left unfixed. This is partly because the codebase has grown, partly because we've all been very busing trying to fill in the gaps and partly because we're all limited in the amount of time we have to code. So now its time we started to focus on quality a little more, and that begins with making what we have stable. Most of these bugs are only an hour or so's work to fix, but they mount up! Syllable will be a much nicer place to be with the release of 0.4.5 :)

    Syllable is however in development, so new features are still being added. I don't see a problem with fixing old bugs while we add new features :) If we had declared the system stable and then started adding features, then I would agree with you. As it is, these features we hope to have in 0.4.5 have been planed for some time, and are required for the core functionality of the OS. The Registrar is one of these, for example.

    So yeah, while we do not have a definite feature list for Syllable 1.0 yet, we do have a good idea of what is clearly going to be needed now. I've exercised my bonevelent dictatorship and picked the ones that best suit our goals, and I shall be more than happy to accept them into the codebase for Syllable 0.4.5.

    We shall also have a proper roadmap and featureset for 1.0 before we start on the 0.5.x versions.