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

 



Forgot your password?
typodupeerror
×
Announcements Operating Systems BSD

Eclipse/BSD Released by Bell Labs 118

howardjp writes "Bell Labs has released Eclipse/BSD, a quality of service research platform based on FreeBSD 3.4. From the Web page: 'Eclipse provides flexible and fine-grained QoS support for applications. Its design allows legacy or Eclipse-unaware applications to provide QoS without the need of modification or recompilation. A simple API is provided for (new) applications to take addvantage [sic] of the fine-grained QoS support.'"
This discussion has been archived. No new comments can be posted.

Eclipse/BSD Released by Bell Labs

Comments Filter:
  • It seams that this license does not allow you to redistribute "Derivative Works". Does that jive with the BSDL?
    Does Lucent use/modify/redistribute BSD under the BSDL, or do they have other rights whith this code via prior arrangements?
  • >...it was notoriously slow...

    Notoriously slow? I worked on Nemesis and it worked fine. FYI we even had things like Hereitc running on it (it supports X-apps) and were able to apply QoS to them.

    One problem is that by default Nemesis has heap paranoia turned on - this is a debugging aid that checks the heap every time you do a malloc. Turn that off and Nemesis runs quite quickly.

    Nemesis was designed from the ground up to be a QoS operating system, including base support for things like asynchronous I/O. I'd imagine that Nemesis would do a better job of providing QoS over all resources than a hacked BSD.

    For example: Under tradiational X-Windows you have a shared server - so while applications can get guarentees, the moment they start using the X-Server you lose all your benefits - your subject to a shared resource. Nemesis, on the other hand, is vertically structured so that almost all work it done in the client's process. Thus your use of the X-Server is subject to your scheduling parameters - thus no one can steal your time!.

    Have a look at http://www.dcs.gla.ac.uk/~mich ael/work/bin/msn99.pdf [gla.ac.uk] which explains the above in more detail.

    > ...and had little hardware support.

    But didn't Linux until recently? :-)

    -- Michael

  • however, it seems to me that generally you want to provide the best QOS you can.

    Well since that is the default, everyone gets as much disk bandwidth as they ask for (until it runs out), ditto for net bandwidth, ditto for CPU (but with a fair share scheduler with weak volentary QOS -- the nice value)... well there wouldn't be much to release for that would there be?

    It looks like this QOS allows hieractical queueing, so you can set up a policy like "everyone gets as much disk bandwidth as they want, unless we run out, in which cases SETTI at Home gets screwed, and everyone else gets what they want". In other words you can choose to control only what happens if you have run out of disk/network/CPU.

  • For example: Under tradiational X-Windows you have a shared server - so while applications can get guarentees, the moment they start using the X-Server you lose all your benefits - your subject to a shared resource. Nemesis, on the other hand, is vertically structured so that almost all work it done in the client's process. Thus your use of the X-Server is subject to your scheduling parameters - thus no one can steal your time!.

    How do they prevent priority inversion? For example a process I have granted unlimited (or very large) amounts of service too, and a process I have granted only tiny bits of service too, and another in between. The "unlimited" one waits for a disk I/O to complete. The "tiny" one starts an extreamly slow X operation (like fetching the glyphs for a all 64K chars in a 16bit true type font at some huge scale...or a mouse grab...or a PEX operation). The disk I/O completes, and the large one wants to display something, but it can't as the tiny one is doing something. The "in between" process wakes now, and starts doing a non-X thing (say five hours of ray tracing). It has more resources allocated to it then the "tiny" process so I assume it gets to suck them up, but less then the "large" one, which won't matter until the "tiny" one gets enough slop from the middle one to continue.

    Is this handled somehow or can mid-pri processes starve out high-pri ones in the presense of low-pri ones?

  • Well, there is The Dresden Real-Time Operating System Project [tu-dresden.de] which is "a research project aiming at the support of applications with Quality of Service requirements".

    It isn't entirely a Linux version, but "A key component is L4Linux [tu-dresden.de], the Linux server on top of the L4 microkernel; it services standard Linux applications. In addition, separate real time components - designed from scratch - provide deterministic service to real time applications." (They also have their own GPL'ed implementation of the L4 microkernel [tu-dresden.de]



  • Please pardon me for asking this question:

    Will we ever see a Linux version of QoS?

    I suspect that Lucent didn't do a Linux "Eclipse" because Lucent doesn't buy into the GPL mindset. Therefore, if there ever is a need to get a similar thing for Linux, somebody else must take up the task.

    Is there someone like that out there amongst the Linux community?



  • You are wrong, man !

    The movie "Titanic" was rendered using Linux, _not_ FreeBSD.

  • Kind of similar to the GPL, anything I create using Linux becomes the property of the community, to do with as they please...
  • It looks rather the opposite, Lucent is not being raped by a community that believes nobody has the right to their intellectual property. And, while keeping up corporate good will, FreeBSD is just as free today as it was last week. This is the way free software should work and in this respect, the RMS/GNU agenda is a failure of ideology if not a failure of advertising.
  • by howardjp ( 5458 ) on Tuesday February 08, 2000 @08:06PM (#1294089) Homepage
    Actually, it shows just how free it is. Lucent has taken the product and released a version which benefits everyone involved, including the developers of the modification.
  • And how does deriving a more restrictively licensed version of some software restrict the availability and usability of the original? It doesn't, so what's your point? You're still able to use the original freely and are free not to use the restricted work. In other words, NOTHING has changed.
  • Hey, did you know the 'wonderful-folks-who-gave-you-unix' use Microsoft Exchange for their mail servers? :)

    One of the many Lucent employees...
    -matt
    ---
    Wha? TV & Movie Theme Songs? Oh yeah....
  • FreeBSD is aimed at high end stuff. It has SMP and a bunch of perofromance twekaing that the other BSD's lack. That's why it was used for rendering [...]

    Actually, for rendering you don't need SMP at all. You can simply set up a farm of cheap boxes and have each one do a frame at a time. SMP only makes things more expensive and can actually slow things down due to cacheing effects.

    This is what I remember from a discussion on the LKML a few weeks back.


    --
  • Inferno has been basically scrapped off all future roadmaps due to lack of developer and "partner" interest. I spent some time playing with it, and some of it was neat... but frankly nothing special.
    ---
    Openstep/NeXTSTEP/Solaris/FreeBSD/Linux/ultrix/OSF /...
  • PL/I jeeze... ok it may be better then c but... we don't have to go COMPLETELY full circle. Why not something more modern, like clean or ML?
  • YOU FUCKING BSD ASS SUCKING MODERATORS
  • YOU FUCKING BSD ASS SUCKING MODERATORS.
  • YOU FUCKING BSD ASS SUCKING MODERATORS..
  • BSD IS THE DEVIL, PAGAN MODERATORS
  • Troll day. :)

    I dont even have the guts to post an original troll, only to request that trolls be moderated up.
  • by Dast ( 10275 )
    I felt the need to contribute at least something non-anonymously. But, I'm not quite creative enough to make an original troll.

    And that Tux picture was really cool. What did you use to generate it?
  • FreeBSD is aimed at high end stuff. It has SMP and a bunch of perofromance twekaing that the other BSD's lack. That's why it was used for rendering Ccap for Titanic.
    I use OpenBSD and Linux personally.

  • Hate to tell you, but the SMP in FreeBSD is on about the same level as that in the 2.0 series of Linux kernels; a big fat kernel lock that slows you down any time you move from user-space to kernel-space.
  • There is another school of thought that says that it is more important to provide a consistent QOS than a variable QOS that is dependent on system load. I've heard of some work on user interfaces that is consistent with this philosophy. Users will adapt to a faster response time and become irritated when the system doesn't maintain a fast response time, even if the slower response time of a heavily loaded system is the same as the old system's response time. The nervous system and brain tune themselves to the response time of the system.
  • by mcc ( 14761 ) <amcclure@purdue.edu> on Tuesday February 08, 2000 @07:23PM (#1294104) Homepage
    Nobody here knows
    What QOS systems are
    At least i sure don't

    The posts will all be
    offtopic BSD flames
    cruel and ignorant

    Natalie Portman
    will probably dominate
    the whole discussion
  • The BSD would certainly allow anyone to create code, and then to release it with this license. That's very different from saying that this license is similar to the BSD license.
  • So you are supposed to research and develop for something that you won't later be able to re-use? (I haven't even looked at the "current" commercial fee, as that is subject to change without notice.)

    You can do it if you choose to. I'd rather play somewhere else.
  • There is already some support for QoS under Linux.
    I'm not sure how far advanced it is because I haven't lokked at it in a while. There are a number of queuing options in the kernel but I'm not sure what tools and APIs there are to support this in userland. Also, there was a version of rsvp around in 1997 but rsvp seems to have fallen to the wayside.
  • (sigh)
    you CANNOT relicense a piece of BSD licensed code.
    You can certainly use it in any way you like, but the original license must be retained.

    The copyright holder, of course, can release it at any time with any licence.

    BSD does NOT equal public domain.
  • "I suspect that Lucent didn't do a Linux "Eclipse" because Lucent doesn't buy into the GPL mindset."

    You don't have to buy into any mindset to bring a product to the Linux market. However, there is a percpeption out there that you have to toe the "party line" or be miserably flamed into market submission. Despite the best efforts of Redat, SuSE, IBM, SGI, etc., there is a very vocal anti-commercial crowd in Linux. BSD does not have this, so it's only natural that Lucent sees BSD as being more business friendly.
  • "This is why I don't really like the BSD *AT TIMES* because it allows people to take a work, slap a restrictive license on it, and resell it in a way that the people who created the work on which it's based can't even use it freely."

    If you take just five seconds to look at ftp.cdrom.com, you'll find that FreeBSD is still there! Yes it is! Nothing has been stolen. No copyrights have been subverted. No licenses altered. All the code that was free yesterday is still free today and will remain free tomorrow.

    Lucent's patch to FreeBSD is just that, a patch. It is Lucent's code. FreeBSD did not write it, and has no claim over it. It doesn't matter if it's derived code or not, because it's still not FreeBSD's code!
  • I only got as far as "solely for non-commercial" and stopped reading. That's not very BSD, issit? Not very GPL either.

    Dave :)

  • People may have good (technical) reasons to prefer using FreeBSD for a testbed like this. I know some Linux zealots may find this amazing, but it's true.

    Perhaps, but given the license that this system comes with, it is incompatable with a GPL'ed system like Linux.

  • I was more thinking about developing your own routers/network gear/etc when I was framing my reply... for software developed to run on the system, I agree, a bit 'constricting', given that it already has been effectively vetoed by OpenBSD given the modifications and so forth it'd entail.
  • ... it's a research platform... meant to allow and enable development of QoS architecture and/or applications. I don't think it's really intended (nor recommended) for a production environment, though I have not looked at all at it...
  • Correct you are. It was the Matrix that was rendered on FreeBSD boxes. Woop.
  • FreeBSD has a really nice VM system that got extensive tuning for "big iron" applications.
  • How do they prevent priority inversion? For example a process I have granted unlimited (or very large) amounts of service too, and a process I have granted only tiny bits of service too, and another in between. The "unlimited" one waits for a disk I/O to complete. The "tiny" one starts an extreamly slow X operation (like fetching the glyphs for a all 64K chars in a 16bit true type font at some huge scale...or a mouse grab...or a PEX operation). The disk I/O completes, and the large one wants to display something, but it can't as the tiny one is doing something. The "in between" process wakes now, and starts doing a non-X thing (say five hours of ray tracing). It has more resources allocated to it then the "tiny" process so I assume it gets to suck them up, but less then the "large" one, which won't matter until the "tiny" one gets enough slop from the middle one to continue.

    There are several assumptions that you make in this scenario that are fundamentally overturned by Nemesis.

    Firstly, you fundamentally can't do proper QoS support just using a purely priority-based model. Instead you offer scheduling guarantees - for example, for a process with a relatively low requirement for CPU, you might offer 1ms of processing time per 100ms of real time. For a CPU intensive process, you might give it 2ms of processing time per 5ms of real time. Even though the "low-priority" task is being offered far less time than the "high-priority" task, it is still guaranteed to receive the allocation that has been made to it. The Nemesis scheduler can enforce these deadlines, since the kernel itself is incredibly lightweight - more so than many microkernels.

    Secondly, the major problem with offering QoS is working out who is actually causing/benefitting from the work being carried out by the kernel/servers. In a vertically-structured system such as Nemesis, most of the data-path work is moved into the applications themselves, (in shared libraries) rather than being done by servers. So in the case of video, clients render their own pixels into their own memory, and invoke a protected trap into the framebuffer device driver to actually transfer those pixels (over the PCI bus) into their windows on the screen. The trap code respects the CPU scheduling deadlines, effectively causing all of the time consumed in rendering and blitting to be accounted to the application. You can have multiple applications on Nemesis all rendering to the screen (animations, or video being streamed from the disk/network), and the display server is using absolutely no CPU time itself. The display server only has to actually do any work itself when applications want to create/destroy/move windows, or to handle mouse and keyboard events. There is also a separate "X-server" process providing certain X facilities such as the clipboard for legacy applications. Clearly if you have two processes wanting to do a mouse grab, only one of them can do so at any one time - but the important thing is that this shouldn't cause your real-time video conference to break up.

    The same idea is used for network and disk access - the disk driver schedules disk block reads/writes, and the network driver schedules ethernet frames. In each case access controls ensure that applications cannot access packets/blocks that they have no authorisation for; by splitting the work up into very small chunks, the task of scheduling (using guarantees rather than simple priorities) is made much more straightforward. Tasks such as protocol processing for TCP/UDP, or interpreting disk blocks to form file data, are performed by the applications using standard shared libraries.

    More information about Nemesis can be found at:

  • The license only applies to THEIR code, though BSDL allows someone to impose such restrictions.
  • > At least its doing some good because other people are benefitting

    The people who write the patch may be benefitting. Some of their users may be benefitting too. However, if anyone out there was thinking of making a free product that does this, then the existence of a freely-downloadable program which does the same thing has probably dented the number of developers they can get helping them. In other words, the existence of a proprietory product makes it harder for a free one to thrive. So if you allow proprietory derivatives, you may be hurting the free software community.
  • When I first glanced at this article, I just assumed that the licensing terms were the same as FreeBSD. I could easily have gone away assuming this; it's only when I read some comments I realised that it was non-free. A great many people will read the headline and assume that this is BSD-licensed stuff. Obviously if everyone was completely observant this wouldn't be a problem, but maybe the headline should have explicitly mentioned the licensing.
  • Geez, are all the babies on the internet today??

    1) QoS, or quality of service, means you can guarantee a certian level of usability. For example, I could guarentee that your web page will be sent over the net at a speed of 500k. Or for more I could guarentee 1M speed. It's a guarantee of a particular level of utilization. In this case, if you pay more your programs will have priority over others on the same system. You're paying for a minimum guaranteed amount of usability on the OS.

    2) Why must everything be free?? The only people who'll use this are people who are in business, and if they're going to make money using it, why shouldn't Lucent be able to recoup the cost of development? This whole neo-marxist "free the software" thing is great up to a point - the business of business is STILL business. If you want to spend a large amount of time to develop a version and give it away for free, that's fine. But when a company pays people to develop this they need to recoup the costs.
  • Another distro isn't so bad.

    What is bad is that it's become a peice of "Use on One computer only" software, licensed under their own restrictive terms.

    How different is this from FreeBSD?

    This is why I don't really like the BSD *AT TIMES* because it allows people to take a work, slap a restrictive license on it, and resell it in a way that the people who created the work on which it's based can't even use it freely.

    But then, it's your choice as to the license...

    /me thinks... GNU BSD?

    *ASBESTOS SUIT ON!*
  • Then I do hope your post gets moderated up for the sake of people like me :)
  • The QoS in Eclipse/BSD is interesting, but only
    for research.

    Anyone read the license? It's terribly restrictive. Still, for "research" it's pretty interesting.

    What I am curious about is INFERNO. Anyone remember it? A few years ago AT&T (now lucent) was hyping INFERNO as the "be all/do all" operating system that would replace unix and be much better. Well, I haven't heard a thing about INFERNO. Anyone?
  • I appreciate the reply on Inferno (even though this started out Eclipse/BSD).

    You are 100% correct. Inferno has been scraped, and in fact sold off. You can read about it at:

    http://www.lucent-inferno.com/inferno/VitaNuova- NTL.html

    As I see it. Eclipse/BSD and Inferno are very much the same. That is to say, they are both CLOSED, RESTRICTED, PROPRIETARY Operating Systems.

    This is BAD. The reasons why it's bad have been hashed out time and time again.

    As interesting as Eclipse/BSD is, it will undoubtedly follow the firey path Inferno OS took. Maybe it will gain miniscule acceptance for very specialized situations, but in general it is doomed to fail from the start.

    That said. Anyone have any info on Linux QoS?
  • I can see that this is a good idea... however, it seems to me that generally you want to provide the best QOS you can.

    Generally, yes. For some applications, you want guaranteed QoS for some services and the best that you can get for everything else.

    The point is to give certain processes QoS guarantees in the presence of other processes which might be scrambling for the CPU. The point is not to deny QoS needlessly, though you could certainly implement a scheduler which did that if you wanted to (a generalisation of setrlimit). If a process is granted 20% of the CPU bandwidth, it might get more, but it will get at least 20%, guaranteed.

    One example is that of serving streaming media, where the data must be delivered at the correct rate. "The best QoS you can" just isn't good enough. You need real guarantees otherwise the application is useless.

    Some routers (e.g. ATM switching) have very similar constraints. Indeed, if you've ever tried to burn a CD and found it ruined because you couldn't keep the writer's buffer full (maybe a cron job started running part-way through the process), start campaigning for QoS guarantees in your favourite OS now. :-)

  • As interesting as Eclipse/BSD is, it will undoubtedly follow the firey path Inferno OS took. Maybe it will gain miniscule acceptance for very specialized situations, but in general it is doomed to fail from the start.

    Eclipse is a research project. I thought Inferno was to be a product. I assume, therefore, that they have different goals: Inferno to make money and Eclipse to test ideas.
  • Is that so strange (no).

    Whould you have asked the same question about a FreeBSD version of QoS if the announcement would have been on Linux/Eclipse?

    People may have good (technical) reasons to prefer using FreeBSD for a testbed like this. I know some Linux zealots may find this amazing, but it's true.

    btw. I'm running Slackware Linux.

  • Interesting that they Chose FreeBSD. Obviouly, they would choose BSD for its less restrictive (or more, depending on which side you look at it) license. But why FreeBSD? It only supports x86 and Alpha at the moment (last time i checked) and its no where close to the security of OpenBSD. On the other hand, NetBSD has been ported to every mechanical device ever made. The only reasons I could think of that they would use FreeBSD over the other (better) 2 is that i don't think OpenBSD (dont know about netbsd, but since they started from the same origins...) supports SMP yet and most un-enlightened folks don't know about the other two. And I must say that BSD users aren't annoying little children like that glue sniffing crack-whore with the penguin ascii from the earlier posts. I bet the little script kiddie hasn't even used BSD. I bet he is running redhat with every possible service running with his L33t w4r3z ftp and his k-r4d eggdrop bot. Atleast the Natalie Portman comments are funny, but that guy is just an idiot who hurts the image of the whole linux community.
  • Thats as ironic as the fact that the 'wonderful-folks-who-gave-you-windows' run unix and Apache for their hotmail servers.
  • from the looks of it this is basically FreeBSD with some nifty patches on top. i'm no guru, but the impression i get is it lets the admin configure how much load to give out for each process. for instance they have a mod for apache so mr. root can give priority to one virtual host over the other. some other features on the site include..

    hierarchical proportional-share cpu, disk and link schedulers,

    the /reserv file system providing an API to manipulate "reservations",

    a tagging mechanism for the association of reservations with schedulable operations.

    to install the sucker you have to already have FreeBSD 3.4 -CURRENT and it installs on top of that. i assume the choose FreeBSD due to it's good SMB support. -Jon

  • I also worked on Nemesis and agree with what Michael says. It was far from perfect in implementation, but the whole point was to demonstrate the principles of providing QoS, not provide a particularly polished final system (really, the whole point of any kind of research). It would be a complete waste of time and money to implement drivers for every device under the sun!

    As Michael pointed out, Nemesis uses a completely different architecture to most other operating systems (ie. migrating OS code into applications) to allow it achieve QoS. You simply cannot do this with a UNIX variant, because you are still relying on time in the kernel (or shared servers) to some of the work that should be accounted to you.

    Just for interest, Nemesis is now available for download [sourceforge.net] at Sourceforge. You can also download the packages from Glasgow (one of the partner sites) here [gla.ac.uk].

  • I can see that this is a good idea... however, it seems to me that generally you want to provide the best QOS you can.

    Of course, I can see someone running several virtual servers on a server setting a lower QOS for their clients than for the main site on the machine...

  • Does any one else see it funny that Bell Labs,
    from AT&T the original owners of "True Unix",
    have BSD in their name?..

    i do at least. I wonder if their "BSD" uses SRV4
    style init files :-)
  • And with whom are "you" in allegiance?
    AFAICT, BSD code runs on many other Unix systems.
    Unfortunately, this is not the case for a lot of
    software developed on Linux systems.

    - Hubert
  • Yes, you are correct sir! (in my best Ed McMahon voice)

    However, there is work being done on finer grained SMP support. All SMP usually starts out at the gigantic kernel lock. Look for the future. However if its processor scalability you look for, Linux isn't even the way to go (although if you need Open Source, well it *is*), but SYSV based OS's like SCO UnixWare or Solaris. BSD's strength is in networking.

    The real reason Lucent chose FreeBSD was probably licensing, and the fact that FreeBSD is generally used more commercially then Net or Open BSD's anyway. OpenBSD is getting there though =)

    -Pat
  • by Cellechan ( 127669 ) on Wednesday February 09, 2000 @05:03AM (#1294139) Homepage
    Its EXTREMELY BSD. the BSDL essentially says "you can take this source code, modify it, and relicense it, as long as you indemnify the original authors and give due credit"

    This is prefectly within anyone's rights, in fact, the BSD community ENCOURAGES this type of thing.

    Remember, us as BSD developers want to make money off our code, and be compensated for time spent. The Bell Labs/Lucent people have spent alot of time and money into these modifications. If you don't like the licensing terms, you can take the FreeBSD 3.4 code and modify it yourself, OR just simply not use it.

    The GPL has nothing to do with this. the GPL is a completely different license, that does not allow for this type of thing. Had it allowed for modification and sale of Linux source, then Lucent *might* have used that instead.

    Remember, each license has a different goal in mind. the GPL is "Viral" and is inherited by its children. The BSDL only effects one generation unless the person modifying also applies the BSDL.

    -Pat
  • I don't care that some company takes my code and uses it. At least its doing some good because other people are benefitting.

  • Be careful, guys - Lucent have given it a non-commercial-use license, for use on only one computer. The appropriate part:

    "The Source Code, Documentation and Derivative Works (collectively "Licensed Software") may be used by you, or an organization of which you are a member or employee, solely for non-commercial, educational, evaluation and/or personal use on a single computer. "Non-commercial use" means uses that are not or will not result in (a) the sale, lease or rental of the Licensed Software; and/or (b) the use of the Licensed Software in any commercial product or service."

    Commercial use requires a separate license which has to be negotiated with Lucent, so you won't be able to use this on a production machine.

  • by Akaji Monkey ( 138442 ) on Tuesday February 08, 2000 @07:27PM (#1294143)

    If you'd taken the time to look at the site, you would have seen that they are distributing a *PATCH* against FreeBSD 3.4, not the entire distribution. That means that the license applies only to the code they've written, not to the BSD source.
  • ...Benefits everyone involved, especially Lucent:

    2. OWNERSHIP: The Source Code and Documentation are and will remain the sole property of Lucent Technologies. The Source Code and Documentation are copyrighted works and protected by copyright law and/or contains proprietary information protected at law. Lucent Technologies may at any time assign or transfer all or part of its interests in any rights to the Licensed Software.

    You agree to treat any modification or derivative work of the Licensed Software as if it were part of the Licensed Software itself. In return for this license, you grant Lucent Technologies and its affiliates a non-exclusive perpetual paid-up royalty-free license to make, sell, have made, copy, distribute and make derivative works of any modification or derivative work you make of the Licensed Software. At Lucent Technologies' request, you will provide Lucent Technologies with a copy of any modification or derivative work of the Licensed Software.

    So anything you create using this effectively becomes the property of Lucent, to do with as they please...
  • There has been a fair amount of research into QoS OS's, one of them being Cambridge University Nemesis Operating system. Unfortunately, it did not really go very far as it was notoriously slow and had little hardware support. It would be interesting to see this do better.... aas

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Working...