While it's a cool hack, the "game console" hardware is not designed with expandability in mind. What would be nice would be to:
Add in a 10BaseT NIC, or, better still, a 100BaseT NIC;
Add another 64MB of RAM.
Those factors would likely make such a unit pretty useful as a "cheap terminal," rather like the $200 Think NIC units.
Unfortunately, I suspect the cost and effort would outweigh the cost of a Think NIC, meaning that while the concept is still a "cool hack," it's not a terribly practical one...
On the one hand, it is somewhat useful to periodically have some "small disasters," as they cause people to be a bit more prepared for "bigger gulps."
For instance, the East Coast Ice Storm of a couple years ago that destroyed the trees of Vermont, Quebec, Ontario, and probably a couple of other states had the "merit" that people had a nice "dry run" on emergency preparations so that they KNEW that they were ready for whatever hiccups might come out of the "Y2K Disaster."
On the other hand, the deaths of trees, destruction of property, and such, was NOT a good thing. And few would argue that World War II was a nice thing in having "showed us how bad tyranny can get."
So while I'll go along with the notion that if bad licenses come along once in a while, it is useful in keeping everyone else "resilient" against it, it's not a particularly Good Thing.
I've downloaded the code and browsed it; I'm not entirely certain precisely what Tux is.
Is it:
A "hack" designed to make IIS look as stupidly slow on carefully "hacked-at" benchmarks as the IIS benchmarks make Apache look?
No particular flaming intended here; in either direction, this represents "benchmarketing" as opposed to anything realistic.
It may be as unrealistic to "real world" situations to use a highly tuned combo of TUX and Apache and make IIS "look sick" as it was for Mindcraft to use a heavily tuned IIS to make a poorly-tuned Apache look bad.
Something that would be embedded into a sophisticated web application framework to make certain cases of page accesses run ravingly fast ?
In which case someone building the next Slashdot might care, as they need to write finely-tuned code, whereas I, when running a lightly loaded web server at home, will have a hard time detecting differences between Roxen, Apache, Boa, and WN.
Something that I could run in lieu of Boa as a tiny, fast web server?
This isn't quite a flame; it truly is important for a piece of software that you want people to use to be described in an economical manner that makes it easy for people to determine its relevance.
IPP is old news. The CUPS implementation was discussed long ago on Slashdot.
The only new thing about this seems to be the introduction of the use of HTTP, seemingly predicated on the consideration that this gets you past the firewalls that hide the other ports.
Which makes this about as secure as SOAP, which essentially implements DCOM atop HTTP.
While it would be nice to have something a bit more sophisticated than LPD , that's hardly news when I've heard "Maddog" Hall comment on this more than once, and I don't hear him lecture every year.
A lot of the interactions that need to be of concern are not the "Human-Computer" ones, but rather those where the computer is "talking to itself."
This includes:
The whole "registry" thing.
There is various information that needs to be persistent to one degree or another. On Windows, this tends to be saved in the Registry of "renoun and much denigration."
On Linux, such data typically sits in the hordes of files in /etc and in $HOME/.*rc
The semantics of how this all works has rather a lot of effect on how applications start up, even though it sits "under the covers."
Similarly, when applications 'talk to one another,' whether via OLE, COM, CORBA, RPC, HTTP, or ICE, this has rather a lot of effect on system behaviour, even when the protocols hide "below the skin."
The use of serialized data transfer protocols ( e.g. - the "Save File" dialog) as opposed to persistent database schemes similarly can make systems work way different even though the appearance of what gets shown on screen may have minimal difference.
It's a small additional step to get to "transactional" systems, where once updates are "committed," they are really permanent. Think Tuxedo/Encina...
These three "views" all have in common that they have nothing to do with which GUI library you're using to build your applications, or what icons are used.
The fact that they're not particularly "visible" does not make them any the less important in the overall scheme of things.
After all, if the gentle user can shut down (perhaps pressing the power switch!), and expect to power up again tomorrow and have everything go to where it was when they pressed the switch, that has lots of effect on user behaviour, whether they "click on save" continually, or not.
My thought here is that a lot of the "HCI" changes taking place don't always need to involve things that are manifestly graphical. A Massively Improved World may "simply" involve systems that are reliable and provide persistent data as opposed to "3D Rotating Splash Screens."
The two notable "paradigms" associated with GUIs are of:
WIMP - Windowed Interface with Mouse Pointer
This "model" has become fairly much dominant, and continues to undergo various forms of "tweaking," lately with everyone going gonzo over Themes.
Unfortunately, major changes require either nuking the whole thing and starting from scratch, which is a lot of work, or else making systems of more and more byzantine complexity to operate.
The latter is where adding additional "stuff-to-click" takes us. Every added toolbar results in another "hieroglyphic" language, moving us towards ancient Egyptian rather than anything modern. (The McLuhan "Laws of Media" strike again...)
MVC - Model/View/Controller
The more "intelligent" sorts of changes don't necessarily involve increasing the visible complexity, but rather trying to split systems more clearly into this paradigm of designing, somewhat separately, an underlying model, a set of controller functions to control the object, and then some form of "front end," or "view."
It's hardly new; Smalltalk and NeXTStep promoted the MVC "view of the world" umpteen years ago, and the problem really is that the ad-hoc GUI construction systems have so often conflated M, V, and C together that many GUI applications wind up as jumbled sets of functionality.
With the dearth of volunteers actually willing to be there to do easy things like Linux Demo Days and the likes, it makes little sense to try to plan to manage the Huge Event.
It seems to me to make more sense to make use of those visits of luminaries that already take place. And to use the "promotional events" that already regularly take place.
Kendall Clark has done a number of interviews with local newspapers, and Chris Cox has been heavily invested in doing presentations on Linux at various local conferences, most recently at the ITEC conference.
Jon Hall comes to town fairly regularly, and I'd count that event, which drew the better part of a thousand people to be a "promotional event." And I believe there are plans for a visit by Randal Schwarz.
Monthly meetings of both NTLUG and DFWUUG commonly draw hundreds of people each month.
Are those not "promotional events"?
In any case, I can't take terribly seriously the criticisms of someone with so "willing" an attitude to take responsibility that they declare themselves to be an Anonymous Coward.
I'm certainly not throwing blame at the LUG; I have had just enough association with conferences that even if they were responsible for the troubles, I'd be happy with chalking it up to a bit of overambition combined with the other parties involved getting way out of hand.
The problem is that if the show "bombed," people that don't understand show organization will "blame" the locals, even if it's IDG or some such "event" group that was truly responsible.
The fact that responsibility isn't completely clear is part of why NTLUG hasn't proceeded; we've heard enough horror stories of conference organizers playing political games that this plays into a reluctance to encourage an event to happen.
One of the things the local LUG, NTLUG periodically hashes over is the notion of trying to "have a conference here in DFW."
That was one of the reasons why we incorporated, so that there would be a "shell" there around which such activities could grow.
But we concluded about a year ago that having "a Linux show" here would require really fine-tuning the purpose, in that there are just so many others.
There's effectively more shows than companies to help sponsor them, especially after the Venture Capital has died to a trickle.
Linus Torvalds can only attend so many shows per year.
For those companies that "sell" on the show floors, it has got to be a lot of work to pick up shop and move, as hobos, from show to show.
This is not something that most would want as a career.
It's a lot of work to put on a show, whether it be small or large. It sounds like the Kansas group got overambitious, which is quite regrettable, as there will be some unfortunate fallout.
Linux isn't yet, by itself, a good enough reason for the existence of a laptop product.
Unless you can get economies of scale from selling lots of 'em, the problem of low volume will result in high prices.
No WordPerfect, and limited maturity of web browsers.
I'm still watching for the first release of OpenPPC hardware; it too is not expected to be inexpensive. TotalImpact cards sound rather cool, but are apparently expensive enough that the vendor isn't willing indicate any pricing information on their web site; reportedly about $1K per CPU.
The "pricing structure" behind the PPCs just doesn't seem suited to laptop deployment that occurs "because they're low powered."
I rather doubt that there are many vendors of StrongARM motherboards in Saskatoon; it is not a city generally considered a "hotbed" of embedded systems development. They've got potash (somewhere), wheat, and some heavy oil. A whole whopping lot of roads to maintain, and with a not-increasing-very-quickly tax base, increasing demands by the Indian community, and younger folk apparently migrating to other provinces, this does not lead to good things. (My dad grew up in North Battleford, and moved to Ottawa "as soon as he could.")
More likely is that you'd have to order it mail order, and thus have atrocious shipping and excise costs.
Getting Quakeforge running sounds pretty cool, but I doubt it would be economically feasible...
Unfortunately, what's less filled is your wallet, especially if you live in Saskatoon or (my favorite) North Battleford.
The problem is that while the boards may outperform a "cheap Pentium," they're priced at the price of a motherboard and a 700 MHz Pentium III, which is not exactly a "cheap Pentium."
If you're in Saskatchewan, you're probably looking at the motherboard and CPU costing you $1K CDN, plus whatever sales taxes get assessed.
What it's suitable for is as a "test bed" if you are planning to design embedded systems based on StrongARM.
If the plan is to deploy it in its own right, it's terribly overpriced.
I might build one "on a whim" if I could get mobo and CPU for $150.
But for $550, just for the mobo/cpu, I suspect it'll see few takers outside of people that need test beds for developing embedded systems.
Actually, I seem to recall seeing this site referenced, probably on Slashdot, a few months ago as a "source of StrongARM motherboards." Based on RCS logs, I've had a link at My Linux VAR page since January 14, 2000, which probably means that this purported "news" is actually "olds," likely mentioned at Slashdot in early-to-mid-January. I noticed then that the pricing was "a bit frightening."
Whether you love or hate the hordes of bureaucrats out there in "GovernmentLand," a government policy that they can't set down in way that the bureaucrats have both:
Method to administer and
Desire to administer
is not likely to turn out well.
If everyone votes that:
Yes, we hate people that cut us off in traffic; put those people
to death!
this does not mean that anybody will get put to death tomorrow or ever.
The only way that cool new proposal works is if you have the proper combination of police, judiciary, and administrators to actually implement the proposal.
Unfortunately, the "natural" result of this "fine-grained" democracy is that people will vote, assortedly, to:
Diminish the number of government employees
Diminish their tax burdens
The first two items are compatible... but then add...
Add additional government services, policies, or regulations...
...Which, due to the previous votes, there is no longer staff or funding to administer.
Sure, you can become a "snakeoil salesman," and gain power and money by collecting lobbying monies. But the notion that this is likely to make for good government should be disabused quickly...
If there were others doing VFS hacking, this would likely have some of the following effects:
They might trample on one another.
I change this, you change that, we break each others' code.
This is different from device drivers, which are pretty independent of one another; the pervasive use of VFS in ext2 means that changes have to filter through someone in order for there to be hope of coherency.
Linus may accept Al Viro's changes, even when they involve changes of VFS design, but be reluctant to accept others' changes to VFS design.
Note that if Linus accepts changes from other people, as well as Al Viro, nothing stops Al from submitting patches that essentially reverse out others' changes in favor of his own. That would be not nice, to be sure.
The side-effect of "patch preferences" is that if Linus accepts changes preferentially, those that aren't preferred won't necessarily take this gracefully, and may decide that there's no point to trying to work on VFS if their efforts are doomed to be ignored.
The strong comments Hans Reiser has made indicate that he falls into the "won't take this gracefully" camp.
Reiser has suggested that there's a "Red Hat" conspiracy; I don't believe that, but it is sure that there have been some disagreements between ReiserFS developers and Al Viro...
... But there actually are some rather smart people working at Microsoft Research.
Just because it's fun (and easy!) to bash the parent company does not mean that the research division is composed of hairy-backed, knuckle-dragging cretins.
The problem is that there's too much variation in the way that C can be written and deployed to treat it as a nice "portable assembler."
The reason is that the C standard had to be open to the use of C for quite a lot of specific applications, notably including embedded applications, that aren't really representative of of the "portable assembler" intent.
In addition, C-- adds in semantics relating to memory management, garbage collection, and such, that C actively eschews, and which C++ left out for so long that it seems unrealistic for it ever to cleanly address.
C-- is intended, as the article suggests, as a "portable assembly language."
Thus motivated, some colleagues and I have been working on the design of C--, a portable assembly language. C-- has to strike a balance between being high-level enough to allow the back end a fair crack of the whip, while being low level enough to give the front end the control it needs. A major goal is to provide portable support for features needed by advanced languages, such as garbage collection, exception handling, and debugging, without building in a particular garbage collector, exception semantics, or debugging model.
There actually are some implementations available in source form.
Microsoft may produce some software of frightening quality, but that doesn't mean that the people that they hire are ignoramuses, but merely that:
"What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water." -- Matt Welsh
Libel tends to be the form of defamation that is made in a permanent and public form, such as in a newspaper or letter.
Slander tends to come in a more transitory form.
This seems somewhat more like slander.
In any case, if the security company isn't abject in their apologies, then it seems likely that they are vulnerable to a lawsuit in the matter, assuming we're talking about the litigation-happy United Suers of America.
It's probably a rather better idea to sue the security company than to draw the employer into the fray...
Thanks for hiring me, albeit a bit late. By the way, I'm suing you!
There is doubtless room for the damages to be significantly more than the one week's worth of wages, from two perspectives:
Who's to know how much this may have injured the reputation of the "accused"?
There may be room for punitive damages to discourage making such mistakes in the future...
What's all too common is for people to react with:
"Cool! A new OS! When will they port [mundane UNIX stuff] to it to make it useful?"
I was reacting generally against that; while it would be nice if there are some "creature features," as well as some "past functionality," that certainly does not lead in the direction of really coming up with cool NEW stuff.
There's lots of dilemma here; a problem with an utterly different OS, like EROS, is that of having an environment capable of hosting it.
For instance, in order to use EROS, which doesn't support "files," as such, you need to take a bunch of C and C++ files and compile them. This pretty much mandates having something that "smells like UNIX" kicking around, to provide:
A filesystem
The G++ toolset
Probably some other "GNU stuff."
Any self-respecting system will be "self-hosting;" you get:
Systems descended from mainframes;
Systems descended from RSX-11;
Systems descended from System 34 and Hydra;
Systems descended from Multics;
A few Lisp environments that are getting pretty unsupportable (well, there's Genera);
FORTHs
And that's about it. (Heh, heh, I didn't mention Linux or Unix. They're "descended," loosely, from Multics... Guess where Windows falls in?:-))
Most of these systems have pretty much converged into general similarity, perhaps save for Lisp and FORTH, although the most recent environments getting deployed for those rest upon either POSIX or Win32.
Based on the above set of ancestors and their children, I'm actually not sure that it's not a reasonable idea to assume the presence of something looking like a POSIX subsystem that could support stuff like GNOME, Perl, and Python.
Slashdot Mirror
Those factors would likely make such a unit pretty useful as a "cheap terminal," rather like the $200 Think NIC units.
Unfortunately, I suspect the cost and effort would outweigh the cost of a Think NIC, meaning that while the concept is still a "cool hack," it's not a terribly practical one...
Not that this is likely to work too well with a DreamCast unit; I suspect they don't do DSL...
Sadly, the late W. Richard Stevens is not on that list; he would not be an interesting interview unless Slashdot has some supernatural interviewers.
Some interesting adds I'd suggest:
Of fame for the "worse is better" thesis
One of the designers, at Apple, of the Dylan language, previously involved in designing Common Lisp, and Symbolics machines.
Noted for involvement with famous books on C, Scheme, Lisp, and Java.
For instance, the East Coast Ice Storm of a couple years ago that destroyed the trees of Vermont, Quebec, Ontario, and probably a couple of other states had the "merit" that people had a nice "dry run" on emergency preparations so that they KNEW that they were ready for whatever hiccups might come out of the "Y2K Disaster."
On the other hand, the deaths of trees, destruction of property, and such, was NOT a good thing. And few would argue that World War II was a nice thing in having "showed us how bad tyranny can get."
So while I'll go along with the notion that if bad licenses come along once in a while, it is useful in keeping everyone else "resilient" against it, it's not a particularly Good Thing.
Is it:
No particular flaming intended here; in either direction, this represents "benchmarketing" as opposed to anything realistic.
It may be as unrealistic to "real world" situations to use a highly tuned combo of TUX and Apache and make IIS "look sick" as it was for Mindcraft to use a heavily tuned IIS to make a poorly-tuned Apache look bad.
In which case someone building the next Slashdot might care, as they need to write finely-tuned code, whereas I, when running a lightly loaded web server at home, will have a hard time detecting differences between Roxen, Apache, Boa, and WN.
This isn't quite a flame; it truly is important for a piece of software that you want people to use to be described in an economical manner that makes it easy for people to determine its relevance.
The only new thing about this seems to be the introduction of the use of HTTP, seemingly predicated on the consideration that this gets you past the firewalls that hide the other ports.
Which makes this about as secure as SOAP, which essentially implements DCOM atop HTTP.
While it would be nice to have something a bit more sophisticated than LPD , that's hardly news when I've heard "Maddog" Hall comment on this more than once, and I don't hear him lecture every year.
Given the choice of:
- Keeping your business open to FBI wiretapping, and
- Not having your business open to FBI wiretapping,
what would people rather have?This includes:
- The whole "registry" thing.
- Similarly, when applications 'talk to one another,' whether via OLE, COM, CORBA, RPC, HTTP, or ICE, this has rather a lot of effect on system behaviour, even when the protocols hide "below the skin."
- The use of serialized data transfer protocols ( e.g. - the "Save File" dialog) as opposed to persistent database schemes similarly can make systems work way different even though the appearance of what gets shown on screen may have minimal difference.
These three "views" all have in common that they have nothing to do with which GUI library you're using to build your applications, or what icons are used.There is various information that needs to be persistent to one degree or another. On Windows, this tends to be saved in the Registry of "renoun and much denigration."
On Linux, such data typically sits in the hordes of files in /etc and in $HOME/.*rc
The semantics of how this all works has rather a lot of effect on how applications start up, even though it sits "under the covers."
It's a small additional step to get to "transactional" systems, where once updates are "committed," they are really permanent. Think Tuxedo/Encina...
The fact that they're not particularly "visible" does not make them any the less important in the overall scheme of things.
After all, if the gentle user can shut down (perhaps pressing the power switch!), and expect to power up again tomorrow and have everything go to where it was when they pressed the switch, that has lots of effect on user behaviour, whether they "click on save" continually, or not.
My thought here is that a lot of the "HCI" changes taking place don't always need to involve things that are manifestly graphical. A Massively Improved World may "simply" involve systems that are reliable and provide persistent data as opposed to "3D Rotating Splash Screens."
This "model" has become fairly much dominant, and continues to undergo various forms of "tweaking," lately with everyone going gonzo over Themes.
Unfortunately, major changes require either nuking the whole thing and starting from scratch, which is a lot of work, or else making systems of more and more byzantine complexity to operate.
The latter is where adding additional "stuff-to-click" takes us. Every added toolbar results in another "hieroglyphic" language, moving us towards ancient Egyptian rather than anything modern. (The McLuhan "Laws of Media" strike again...)
The more "intelligent" sorts of changes don't necessarily involve increasing the visible complexity, but rather trying to split systems more clearly into this paradigm of designing, somewhat separately, an underlying model, a set of controller functions to control the object, and then some form of "front end," or "view."
It's hardly new; Smalltalk and NeXTStep promoted the MVC "view of the world" umpteen years ago, and the problem really is that the ad-hoc GUI construction systems have so often conflated M, V, and C together that many GUI applications wind up as jumbled sets of functionality.
It may be that introducing things like Glade User Interface Builder along with libglade , to encourage keeping "controller" stuff in once place, GNOME-print, Gnome Canvas, DPS for XFree86, and Display Ghostscript, ReportLab, providing "view" tools, and CORBA, providing separation of "model," may provide a direction to clearly separate these functions so that GUIs will be less confused.
None of this represents dramatic, overnight change, and I'm not sure that that's a bad thing.
With the dearth of volunteers actually willing to be there to do easy things like Linux Demo Days and the likes, it makes little sense to try to plan to manage the Huge Event.
It seems to me to make more sense to make use of those visits of luminaries that already take place. And to use the "promotional events" that already regularly take place.
Are those not "promotional events"?
In any case, I can't take terribly seriously the criticisms of someone with so "willing" an attitude to take responsibility that they declare themselves to be an Anonymous Coward.
The problem is that if the show "bombed," people that don't understand show organization will "blame" the locals, even if it's IDG or some such "event" group that was truly responsible.
The fact that responsibility isn't completely clear is part of why NTLUG hasn't proceeded; we've heard enough horror stories of conference organizers playing political games that this plays into a reluctance to encourage an event to happen.
That was one of the reasons why we incorporated, so that there would be a "shell" there around which such activities could grow.
But we concluded about a year ago that having "a Linux show" here would require really fine-tuning the purpose, in that there are just so many others.
This is not something that most would want as a career.
It's a lot of work to put on a show, whether it be small or large. It sounds like the Kansas group got overambitious, which is quite regrettable, as there will be some unfortunate fallout.
It sounds to me like they're recreating what IIOP provides, and with the added cost that you need to encode data in the rather wasteful XML format.
I half figure that someone will eventually build an "XML over IIOP" scheme that will allow compressing it.
The Casbah project's LDO provides another alternative.
I'm still watching for the first release of OpenPPC hardware; it too is not expected to be inexpensive. TotalImpact cards sound rather cool, but are apparently expensive enough that the vendor isn't willing indicate any pricing information on their web site; reportedly about $1K per CPU.
The "pricing structure" behind the PPCs just doesn't seem suited to laptop deployment that occurs "because they're low powered."
More likely is that you'd have to order it mail order, and thus have atrocious shipping and excise costs.
Getting Quakeforge running sounds pretty cool, but I doubt it would be economically feasible...
The problem is that while the boards may outperform a "cheap Pentium," they're priced at the price of a motherboard and a 700 MHz Pentium III, which is not exactly a "cheap Pentium."
If you're in Saskatchewan, you're probably looking at the motherboard and CPU costing you $1K CDN, plus whatever sales taxes get assessed.
What it's suitable for is as a "test bed" if you are planning to design embedded systems based on StrongARM.
If the plan is to deploy it in its own right, it's terribly overpriced.
But for $550, just for the mobo/cpu, I suspect it'll see few takers outside of people that need test beds for developing embedded systems.
Actually, I seem to recall seeing this site referenced, probably on Slashdot, a few months ago as a "source of StrongARM motherboards." Based on RCS logs, I've had a link at My Linux VAR page since January 14, 2000, which probably means that this purported "news" is actually "olds," likely mentioned at Slashdot in early-to-mid-January. I noticed then that the pricing was "a bit frightening."
- Method to administer and
- Desire to administer
is not likely to turn out well.If everyone votes that:
this does not mean that anybody will get put to death tomorrow or ever.The only way that cool new proposal works is if you have the proper combination of police, judiciary, and administrators to actually implement the proposal.
Unfortunately, the "natural" result of this "fine-grained" democracy is that people will vote, assortedly, to:
The first two items are compatible... but then add...
Sure, you can become a "snakeoil salesman," and gain power and money by collecting lobbying monies. But the notion that this is likely to make for good government should be disabused quickly...
- They might trample on one another.
- Linus may accept Al Viro's changes, even when they involve changes of VFS design, but be reluctant to accept others' changes to VFS design.
Reiser has suggested that there's a "Red Hat" conspiracy; I don't believe that, but it is sure that there have been some disagreements between ReiserFS developers and Al Viro...I change this, you change that, we break each others' code.
This is different from device drivers, which are pretty independent of one another; the pervasive use of VFS in ext2 means that changes have to filter through someone in order for there to be hope of coherency.
Note that if Linus accepts changes from other people, as well as Al Viro, nothing stops Al from submitting patches that essentially reverse out others' changes in favor of his own. That would be not nice, to be sure.
The side-effect of "patch preferences" is that if Linus accepts changes preferentially, those that aren't preferred won't necessarily take this gracefully, and may decide that there's no point to trying to work on VFS if their efforts are doomed to be ignored.
The strong comments Hans Reiser has made indicate that he falls into the "won't take this gracefully" camp.
Just because it's fun (and easy!) to bash the parent company does not mean that the research division is composed of hairy-backed, knuckle-dragging cretins.
The reason is that the C standard had to be open to the use of C for quite a lot of specific applications, notably including embedded applications, that aren't really representative of of the "portable assembler" intent.
In addition, C-- adds in semantics relating to memory management, garbage collection, and such, that C actively eschews, and which C++ left out for so long that it seems unrealistic for it ever to cleanly address.
C-- is intended, as the article suggests, as a "portable assembly language."
There actually are some implementations available in source form.Microsoft may produce some software of frightening quality, but that doesn't mean that the people that they hire are ignoramuses, but merely that:
Don't let them on tour... Please, please, please... Particularly not with the title Oops, I Hacked It Again
Slander tends to come in a more transitory form.
This seems somewhat more like slander.
In any case, if the security company isn't abject in their apologies, then it seems likely that they are vulnerable to a lawsuit in the matter, assuming we're talking about the litigation-happy United Suers of America.
It's probably a rather better idea to sue the security company than to draw the employer into the fray...
There is doubtless room for the damages to be significantly more than the one week's worth of wages, from two perspectives:
What's all too common is for people to react with:
I was reacting generally against that; while it would be nice if there are some "creature features," as well as some "past functionality," that certainly does not lead in the direction of really coming up with cool NEW stuff.
There's lots of dilemma here; a problem with an utterly different OS, like EROS, is that of having an environment capable of hosting it.
For instance, in order to use EROS, which doesn't support "files," as such, you need to take a bunch of C and C++ files and compile them. This pretty much mandates having something that "smells like UNIX" kicking around, to provide:
Any self-respecting system will be "self-hosting;" you get:
- Systems descended from mainframes;
- Systems descended from RSX-11;
- Systems descended from System 34 and Hydra;
- Systems descended from Multics;
- A few Lisp environments that are getting pretty unsupportable (well, there's Genera);
- FORTHs
And that's about it. (Heh, heh, I didn't mention Linux or Unix. They're "descended," loosely, from Multics... Guess where Windows falls in?Most of these systems have pretty much converged into general similarity, perhaps save for Lisp and FORTH, although the most recent environments getting deployed for those rest upon either POSIX or Win32.
Based on the above set of ancestors and their children, I'm actually not sure that it's not a reasonable idea to assume the presence of something looking like a POSIX subsystem that could support stuff like GNOME, Perl, and Python.