The Linux boot sequence and startup was designed for multiuser, timeshared machines. I don't think it's appropriate for the current Linux desktop use.
I've gotten even old, slow machines to boot very quickly (under 10 seconds after LILO prompt) by compiling a non-module kernel and replacing the/etc/rc.d/... stuff with a single/etc/rc script. Of course, none of the standard admin tools know what to do with that sort of thing.
I think rethinking and redoing everything from the time the Linux kernel loads to the time the user gets a prompt or login screen could both simplify administration and speed up booting without sacrificing flexibility.
Many employment contracts for high tech workers state that (1) work that falls within the area of employment is never considered "outside the company", (2) you must disclose any and all outside business interests to your employer right away, so hiding behind "Brand X" doesn't help.
I don't know what your particular contract said and whether what you did violated it; your company may simply have decided that it wasn't worth raising the issue, because they like you, or because your price was right. What I do know is that what you did would violate the employment contracts of many people.
WinCE was going to drive Palm out of business, Windows NT was going to kill UNIX, and all that. And I'm not even talking about Microsoft's failures there, of which there are plenty.
The fact is that Microsoft has had lots of failures and limited successes. So far, Xbox looks to me like it's going to flop. I see little about it that is appealing, and Microsoft's tendency of copying too much from their desktops when moving to other platforms really hurts them and makes their products unattractive. But maybe it will succeed. We'll have to wait and see. But assuming that they have won this market because they announced yet another grand strategy seems pretty silly given their record.
Of course, even with a monopoly, prices can't go arbitrarily high--it depends on price elasticity of demand. Nevertheless, having a monopoly will generally lead to higher prices than having a competitive, efficient marketplace.
There may be benefits to monopolies. For example, AT&T invested so much in research only because they had a monopoly; since that was broken up, their research labs have steadily declined. But that was, in part, due to close government scrutiny and other idiosyncratic factors. I don't expect AT&T research to go back to the old days--I think you can be pretty sure that any profits they get now will be transferred to stock holders one way or another.
Your contract with your company governs who owns what and who can do what. Maybe you are completely in the clear, maybe not. Your company may well be able to claim rights to the software you developed even if you did it "in your spare time".
This is something you should have looked into when you started, not after you invested six months of work. If your contract doesn't clearly allow you to do this sort of thing, get a signed agreement up-front.
Now, from a practical point of view, you may be able to negotiate. After all, you have the code and they want it. Maybe they can "buy" or "license" the code from you. But if they are firmly convinced that they have rights to the code anyway, they may just use negotiations to get whatever they feel is theirs out of you and stop before committing to anything.
Another possible course to follow is to quit your job and market your product. The company may still try to claim rights to your software, but it seems less likely that they would do so. There is programming work you can do even while working on your own projects; contracting is often structured that way.
So, there isn't any easy answer. It all depends on your contract, your personal relationships and trust with people at the company, the potential value of the product, etc. The best lesson to take from this is: think about it beforehand.
What dynamically types remote interfaces and service descriptions did "people" have before CORBA?
Several Lisp and Smalltalk systems implemented dynamically typed remote procedure calls in the 1980's. If you want to count it in, PVM is another example, and there are probably more.
Of course, if we are talking about functionality at the level of SOAP, Lisp had (and has) that essentially built-in: Lisp data structures and function calls can be reliably converted to and from text, and readers and writers are built into implementations. To get SOAP-like functionality in a Lisp system, you need roughly the following:
(setq result (with-input-from-stream (socket) (eval (read))))
(with-output-to-stream (socket) (print result))
There is no magic going on here: these primitives (under various names) are part of pretty much every Lisp system. A complete Lisp system probably takes less code to implement than an XML library. Lisp is just designed for simplicity and functionality from the ground up.
How does CORBA represent a step backwards?
In my opinion, CORBA is an unnecessarily complex standard. The industry would have been served better by concentrating on a simple, dynamically typed system. If real-world applications had called for additional features, those could have been added later on. And, history seems to be proving that view correct: after 10 years of mucking around with CORBA and DCOM, the industry is now going for XML-based RPC.
If you are already fully in Microsoft land, maybe the thought of running PocketOffice gets you really excited. As for me, there are a lot more Linux applications I want to run on a handheld than there are WinCE applications.
Traditional RPC protocols require one to know that a method is of the form:
foobar(int a, int b, char[] c)
With XML, each parameter is defined by a "tag". This allows position independence -- one only
has to state the name of the parameter that the piece of data is for. (Insert analogy to
Smalltalk method parameters here.)
SOAP is kind of ambiguous on the issue of positional or named parameters.
If you want to bind existing code to RPC interfaces, you must support positional parameters and you must ignore parameter names because most existing languages use positional parameters. An RPC binding for Java or C that uses parameter names is simply incorrect because it doesn't reflect language semantics.
"void f(int x)" and "void f(int y)" are the same interfaces in C/C++/Java. If you haphazardly used named parameters, you'd be missing a parameter. Or, if you declare a function as "int f(int x,int y)" in one place and "int f(int y,int x)" in another, you'd be calling the function with the wrong arguments if you used named parameters. The only way you can introduce named parameters for C/C++/Java interfaces is if you add new mechanisms for declaring how named parameters map onto the positional parameters of those languages. In different words, if you adopt a named parameter scheme, you cannot build an automatic mapping from C/C++/Java interfaces onto SOAP interfaces (unless you call your "named parameters" something like "arg0", "arg1",...).
Note that Smalltalk parameters are, in fact, positional: "x put: y at: z" is not the same as "x at: z put: y"; in the first case, the method is "put:at:", in the second case, the method is "at:put:".
Traditional RPC protocols also require you to statically bind to an interface (.h file,.java file, IDL file). This means that when an interface changes, you need to recompile. This sucks.
Yup, dynamic interfaces are nice. Of course, lots of systems had them before CORBA and DCOM side-tracked the industry.
XML RPC frees you from having to use a standard object model, or a standard language. You
can implement an XML RPC endpoint in ANYTHING you want -- there's no model to bind to.
Every call is dynamic.
First of all, XML RPC is not the same as SOAP. In any case, not specifying the object model is not the same as not having one. In fact, SOAP has an object model, it just doesn't specify it. And SOAP's object model maps quite poorly on the object models of existing languages. That isn't freedom, it is merely forcing you to put in a lot of effort in exposing your interfaces in ways SOAP can actually handle them.
[SOAP] defines a standard type encoding (for arrays, structs, etc)
It doesn't really. The current SOAP spec doesn't tell you unambiguously how to represent common datatypes like arrays, strings, or structures. It gives you types that kind of are roughly analogous, but that's all. If these types interoperate between different implementations, it's because of conventions that are outside the SOAP spec, not because SOAP defines a standard.
SOAP is actually pretty typical of vendor standards: it specifies enough to give people a warm and fuzzy feeling, but it isn't sufficient for people to write truly interoperable implementations. That's great for the people who set the standard, it's useless for the industry.
HTTP provides the final value-add in that it's ubquitious, firewall-friendly, and clear-text.
It's too bad that SOAP doesn't commit to HTTP as a transport protocol. Because it doesn't, you can't really rely on HTTP mechanisms when implementing SOAP or defining SOAP-based functionality.
Put simply, using SOAP, two or more 'alien-things' can communicate to each other as long
as they agree on the SOAP protocol - which is the ONLY requirement when doing client/server using SOAP.
Sure CORBA, DCOM, COM+, Java, etc. allow you to enable two different components to talk
to each other,
SOAP isn't an RPC/DO mechanism comparable to CORBA, DCOM, or RMI because SOAP doesn't specify how to encode many common datatypes found in programming languages. It doesn't even tell you how to encode arbitrary strings.
So, it's hard to say what SOAP is. It's not a mechanism for exchanging arbitrary XML documents (and you can do that much more easily via HTTP anyway). And it's not a mechanism for implementing even the simplest forms of RPC involving real programming languages. It's something that looks like an RPC mechanism but doesn't really deliver.
What it really is is whatever Microsoft does and because the spec is so incomplete, you can't reliably interoperate with it. What you can do is reverse engineer a little more easily. Let's be thankful for little favors, but let's not grow overly enthusiastic.
With SOAP, this is all eliminated. As long as the server publishes its API via the SOAP
protocol, I can write my client to talk with the server using what ever I want. This frees me
from having to 'embed' in my client a piece of the server -- thus there is no longer any
'hard-coupling' between two 'things'.
This stuff isn't new at all: people had dynamically typed remote interfaces and service descriptions for years. CORBA/DCOM/RMI actually represented a step backwards when they came out.
Dynamically typed remote interfaces and service descriptions are nice and have all sorts of benefits, but they don't eliminate coupling.
In short, using SOAP, we now enable a true 'smart' data-exchange-protocol between two
systems such that development is now at the level of "data-exchange" rather than API,
SDK, language, etc.
Smart data exchange would require actual smarts: rules, constraints, inferences. There is nothing in the SOAP spec or implementations that supports that. It's extremely naive to assume that those problems will get magically solved merely by using some complicated XML scheme for describing data and services.
The XML community is roughly where the Lisp community was in the 1960's: they are awed by the power and convenience of a universal syntax and dynamic type system and they haven't woken up to the fact that the problems themselves are hard and aren't solved just by having convenient, powerful data types.
Web bugs and other cross-site tracking methods (static IP addresses, as with cable and DSL, are even better for tracking) give advertisers instant information about your interests and browsing history. But they don't just give that information to advertisers, they also give it to on-line businesses that you buy from. If you don't turn this off, when you fill in an on-line insurance or credit application, the company you apply for can get your browsing history just like an advertiser would. It's cheap, it's easy, why in the world would they not do it if they can?
You may say "I have nothing to hide". Neither do I. But the statistical analysis programs that grovel through browsing data are trained on the statistical average. For oddball populations like the readership of Slashdot, they may perform in completely haphazard ways. They might classify you as an educated person with great income potential, based on your fondness of gadgets, or they might classify you as a disturbed sociopath with violent tendencies, based on your fondness for computer games and fast computers you share with the Columbine high school kids. And if you get investigated or have credit or insurance denied because some program misclassified you, you'll never know what hit you.
The only way to deal with this is to not let the information get collected in the first place. Once it has been collected, it's impossible to keep it from being used for discriminatory purposes (in fact, often, that happens completely unintentionally).
You are missing either a configuration that seamlessly talks to existing Outlook clients, or both a client and a server that seamlessly work like Outlook/Exchange and don't require any retraining.
Face it: Outlook/Exchange's popularity isn't about functionality, technology, or features. It's popular because it's, well, popular.
If you are saying that given the bits and pieces we already have, it might not be difficult to create an alternative, you're probably right. But someone has got to do it, and so far, nobody has bothered.
Your chances are good, but why bother? A few miles above earth in a metal can doesn't really seem like much of an experience. You wouldn't even have enough fuel to go anywhere but down if you could hijack the spacecraft.
Mars, Europa, or Titan might be more interesting targets from a personal point of view, but chances of getting there anytime soon look dim. Rationally, even there, I'd prefer detailed 3D imagery and scientific analysis brought back by unmanned probes, rather than wasting money on the ISS and other publicity stunts.
If you want to experience unexplored nature, go into the oceans: cheaper, far less explored than earth orbit, and a lot more interesting. And if you want to actually experience getting close to space, climbing a high mountain gives you a more immediate experience.
Too bad that all the desktops are competing over which one looks visually most appealing/modern/styled.
What about competing on which one is easiest to program for? Which one has the smallest learning curve for programmers? Which one has the lowest footprint and still provides full functionality? Which one is the easiest to use?
If you have a credible record of publications and talks in security, cryptography, OS design, or related fields and you write a good proposal, I think there is a good chance that you will get funded. Of course, if you have any of that, you probably know the people funding and/or reviewing the DARPA proposals already, since DARPA tries to stay in touch with researchers in the fields they are interested in.
Many people do research on reliability and repair costs before buying a new car and will be reluctant to buy a car from a company with no track record. Even VCs give money preferentially to people with track records (most of them won't even talk to you unless you have been referred--it isn't worth their time). If anything, DARPA seems a bit more open to new ideas and new people.
Incrementally improving an existing system that, one way or another is perhaps more secure than the rest of the open source systems, isn't "research". Research is about inventing new principles and finding better ways of doing things.
Perhaps some of this research will be done on top of one of the BSD platforms. Perhaps it will be done on Linux. Perhaps some of it will be completely platform independent. But no matter what it will be done on, there are more interesting research questions to ask about open source, secure operating systems, and heterogeneous environments than whether we can fix a few more bugs in BSD or Linux.
Could this actually have some positive uses as well? Perhaps we could use it to make data storage on hard disks secure in a way that isn't efficiently possible right now--software encryption/decryption is costly and not well integrated into current operating systems.
In fact, it seems to me that many hardware-supported information security mechanisms might end up having these two faces: on the one hand, you may be able to use them to protect your own data, on the other hand, people may be able to build an infrastructure around them that lets them control copying.
While benchmarks aren't perfect, the SPEC results at least give a rough indication of how fast these things might be. Unfortunately, I can't find any information on the Sun Blade 100. Has anybody seen SPECmarks on these things?
The SunBlade 1000 (an UltraSPARC III running at 500MHz) seems in the same ballpark as a high-end Intel or AMD processor, so I wouldn't get my hopes up too high for the SunBlade 100 (an UltraSPARC IIe running at 500MHz); it's probably a reasonable deal compared to PCs, but not great.
The really interesting thing is that that the SunBlade 100 is a 64bit machine for less than $1000.
The hardware sounds like a great deal. But if all it runs well is Solaris, I'm not interested.
We may be discussing the relative merits of Debian vs. RedHat at length, but in my opinion both are stellar compared to Sun's inconvenient administrative and packaging tools. Even if Sun were completely up to speed in those areas, there is still the issue that Solaris puts many files in different places from Linux (and BSD and SunOS, for that matter) and that getting and installing the latest GNU software on Solaris is still a lot more work than on Linux in my experience.
I believe the Debian UltraSPARC port is coming along but not quite complete yet. Anybody have more information? Can you get a basic Linux system with accelerated XFree86, GNU C/C++, Perl, and Python up on these things? What about Sun Java for Linux/SPARC? If the Linux kernel isn't up to speed for UltraSPARC, what about a RedHat Debian distribution built around the Solaris kernel?
Yes, the IEEE Computer Society's on-line library is very useful. But if it is a sign of things to come, we should all be concerned. The IEEE doesn't pay authors, editors, or reviewers for their work, yet in order to publish through them, you have to transfer your copyright. The only reason they can get away with that is because, by historical accident, publication in IEEE journals is important for academic careers.
I very much hope that the IEEE is a temporary aberration when it comes to on-line publishing, because a model in which a few on-line publishers can dictate on the basis of their market position what they pay content creators and charge subscribers is not desirable.
Yes, there is decades long experience with ACLs in UNIX and other systems, and the experience isn't usually good. NT only comes into the picture because Microsoft in general has a habit of putting features into their OS that sound good on feature check lists but may ultimately be bad system design.
There's no reason I, not and service, ever
neeed to run as root. Why does my mail server need a small program with permissions to install a rootkit in/dev? Why
can't I delegate the task of adding and deleting users to a minion without worrying they will corrupt the filesystem.
See, and that's at the heart of the design issue. Many of the "limited" permissions you might construct with ACLs turn out to be equivalent to "root" permissions anyway; having ACLs gives you a false sense of security. Delegation of specific privileges generally only works reliably with very careful programmatic permission checking. That's why UNIX has setuid programs.
I wasn't talking about open source, I was talking about 20 year old commercial technology: Motif, Smalltalk, and others. Those systems allowed users to change both appearance and behavior dynamically. In the case of Smalltalk and similar platforms, you could even replace parts of the actual code at runtime without restarting applications, allowing you to change both behavior and appearance in radical ways.
MacOS and MSWindows originally sacrificed flexibility in order to lower resource requirements. That's nice, but it is wrong to let them patent all sorts of features now that their platforms have caught up in terms of performance that used to be commonplace on high-end machines. (Incidentally, I don't think KDE or Gnome are much better in this regard than MacOS or MSWindows, which is too bad, since they had a chance to do a better job.)
Slashdot Mirror
I've gotten even old, slow machines to boot very quickly (under 10 seconds after LILO prompt) by compiling a non-module kernel and replacing the /etc/rc.d/... stuff with a single /etc/rc script. Of course, none of the standard admin tools know what to do with that sort of thing.
I think rethinking and redoing everything from the time the Linux kernel loads to the time the user gets a prompt or login screen could both simplify administration and speed up booting without sacrificing flexibility.
I don't know what your particular contract said and whether what you did violated it; your company may simply have decided that it wasn't worth raising the issue, because they like you, or because your price was right. What I do know is that what you did would violate the employment contracts of many people.
No offense taken, since we know that you must be talking about yourself.
The fact is that Microsoft has had lots of failures and limited successes. So far, Xbox looks to me like it's going to flop. I see little about it that is appealing, and Microsoft's tendency of copying too much from their desktops when moving to other platforms really hurts them and makes their products unattractive. But maybe it will succeed. We'll have to wait and see. But assuming that they have won this market because they announced yet another grand strategy seems pretty silly given their record.
There may be benefits to monopolies. For example, AT&T invested so much in research only because they had a monopoly; since that was broken up, their research labs have steadily declined. But that was, in part, due to close government scrutiny and other idiosyncratic factors. I don't expect AT&T research to go back to the old days--I think you can be pretty sure that any profits they get now will be transferred to stock holders one way or another.
This is something you should have looked into when you started, not after you invested six months of work. If your contract doesn't clearly allow you to do this sort of thing, get a signed agreement up-front.
Now, from a practical point of view, you may be able to negotiate. After all, you have the code and they want it. Maybe they can "buy" or "license" the code from you. But if they are firmly convinced that they have rights to the code anyway, they may just use negotiations to get whatever they feel is theirs out of you and stop before committing to anything.
Another possible course to follow is to quit your job and market your product. The company may still try to claim rights to your software, but it seems less likely that they would do so. There is programming work you can do even while working on your own projects; contracting is often structured that way.
So, there isn't any easy answer. It all depends on your contract, your personal relationships and trust with people at the company, the potential value of the product, etc. The best lesson to take from this is: think about it beforehand.
However, there is a big literature on distributed computing in Lisp, going back to the early 80's, almost all of which used dynamic typing.
Several Lisp and Smalltalk systems implemented dynamically typed remote procedure calls in the 1980's. If you want to count it in, PVM is another example, and there are probably more.
Of course, if we are talking about functionality at the level of SOAP, Lisp had (and has) that essentially built-in: Lisp data structures and function calls can be reliably converted to and from text, and readers and writers are built into implementations. To get SOAP-like functionality in a Lisp system, you need roughly the following:
Complete client code:
Complete server code:
There is no magic going on here: these primitives (under various names) are part of pretty much every Lisp system. A complete Lisp system probably takes less code to implement than an XML library. Lisp is just designed for simplicity and functionality from the ground up.
In my opinion, CORBA is an unnecessarily complex standard. The industry would have been served better by concentrating on a simple, dynamically typed system. If real-world applications had called for additional features, those could have been added later on. And, history seems to be proving that view correct: after 10 years of mucking around with CORBA and DCOM, the industry is now going for XML-based RPC.
If you are already fully in Microsoft land, maybe the thought of running PocketOffice gets you really excited. As for me, there are a lot more Linux applications I want to run on a handheld than there are WinCE applications.
SOAP is kind of ambiguous on the issue of positional or named parameters.
If you want to bind existing code to RPC interfaces, you must support positional parameters and you must ignore parameter names because most existing languages use positional parameters. An RPC binding for Java or C that uses parameter names is simply incorrect because it doesn't reflect language semantics.
"void f(int x)" and "void f(int y)" are the same interfaces in C/C++/Java. If you haphazardly used named parameters, you'd be missing a parameter. Or, if you declare a function as "int f(int x,int y)" in one place and "int f(int y,int x)" in another, you'd be calling the function with the wrong arguments if you used named parameters. The only way you can introduce named parameters for C/C++/Java interfaces is if you add new mechanisms for declaring how named parameters map onto the positional parameters of those languages. In different words, if you adopt a named parameter scheme, you cannot build an automatic mapping from C/C++/Java interfaces onto SOAP interfaces (unless you call your "named parameters" something like "arg0", "arg1", ...).
Note that Smalltalk parameters are, in fact, positional: "x put: y at: z" is not the same as "x at: z put: y"; in the first case, the method is "put:at:", in the second case, the method is "at:put:".
Yup, dynamic interfaces are nice. Of course, lots of systems had them before CORBA and DCOM side-tracked the industry.
First of all, XML RPC is not the same as SOAP. In any case, not specifying the object model is not the same as not having one. In fact, SOAP has an object model, it just doesn't specify it. And SOAP's object model maps quite poorly on the object models of existing languages. That isn't freedom, it is merely forcing you to put in a lot of effort in exposing your interfaces in ways SOAP can actually handle them.
It doesn't really. The current SOAP spec doesn't tell you unambiguously how to represent common datatypes like arrays, strings, or structures. It gives you types that kind of are roughly analogous, but that's all. If these types interoperate between different implementations, it's because of conventions that are outside the SOAP spec, not because SOAP defines a standard.
SOAP is actually pretty typical of vendor standards: it specifies enough to give people a warm and fuzzy feeling, but it isn't sufficient for people to write truly interoperable implementations. That's great for the people who set the standard, it's useless for the industry.
It's too bad that SOAP doesn't commit to HTTP as a transport protocol. Because it doesn't, you can't really rely on HTTP mechanisms when implementing SOAP or defining SOAP-based functionality.
SOAP isn't an RPC/DO mechanism comparable to CORBA, DCOM, or RMI because SOAP doesn't specify how to encode many common datatypes found in programming languages. It doesn't even tell you how to encode arbitrary strings.
So, it's hard to say what SOAP is. It's not a mechanism for exchanging arbitrary XML documents (and you can do that much more easily via HTTP anyway). And it's not a mechanism for implementing even the simplest forms of RPC involving real programming languages. It's something that looks like an RPC mechanism but doesn't really deliver.
What it really is is whatever Microsoft does and because the spec is so incomplete, you can't reliably interoperate with it. What you can do is reverse engineer a little more easily. Let's be thankful for little favors, but let's not grow overly enthusiastic.
This stuff isn't new at all: people had dynamically typed remote interfaces and service descriptions for years. CORBA/DCOM/RMI actually represented a step backwards when they came out.
Dynamically typed remote interfaces and service descriptions are nice and have all sorts of benefits, but they don't eliminate coupling.
Smart data exchange would require actual smarts: rules, constraints, inferences. There is nothing in the SOAP spec or implementations that supports that. It's extremely naive to assume that those problems will get magically solved merely by using some complicated XML scheme for describing data and services.
The XML community is roughly where the Lisp community was in the 1960's: they are awed by the power and convenience of a universal syntax and dynamic type system and they haven't woken up to the fact that the problems themselves are hard and aren't solved just by having convenient, powerful data types.
My mother uses Windows and doesn't care about KDE. I use UNIX because I do, and KDE doesn't do much for me (neither does Gnome).
You may say "I have nothing to hide". Neither do I. But the statistical analysis programs that grovel through browsing data are trained on the statistical average. For oddball populations like the readership of Slashdot, they may perform in completely haphazard ways. They might classify you as an educated person with great income potential, based on your fondness of gadgets, or they might classify you as a disturbed sociopath with violent tendencies, based on your fondness for computer games and fast computers you share with the Columbine high school kids. And if you get investigated or have credit or insurance denied because some program misclassified you, you'll never know what hit you.
The only way to deal with this is to not let the information get collected in the first place. Once it has been collected, it's impossible to keep it from being used for discriminatory purposes (in fact, often, that happens completely unintentionally).
Face it: Outlook/Exchange's popularity isn't about functionality, technology, or features. It's popular because it's, well, popular.
If you are saying that given the bits and pieces we already have, it might not be difficult to create an alternative, you're probably right. But someone has got to do it, and so far, nobody has bothered.
Mars, Europa, or Titan might be more interesting targets from a personal point of view, but chances of getting there anytime soon look dim. Rationally, even there, I'd prefer detailed 3D imagery and scientific analysis brought back by unmanned probes, rather than wasting money on the ISS and other publicity stunts.
If you want to experience unexplored nature, go into the oceans: cheaper, far less explored than earth orbit, and a lot more interesting. And if you want to actually experience getting close to space, climbing a high mountain gives you a more immediate experience.
What about competing on which one is easiest to program for? Which one has the smallest learning curve for programmers? Which one has the lowest footprint and still provides full functionality? Which one is the easiest to use?
Many people do research on reliability and repair costs before buying a new car and will be reluctant to buy a car from a company with no track record. Even VCs give money preferentially to people with track records (most of them won't even talk to you unless you have been referred--it isn't worth their time). If anything, DARPA seems a bit more open to new ideas and new people.
Perhaps some of this research will be done on top of one of the BSD platforms. Perhaps it will be done on Linux. Perhaps some of it will be completely platform independent. But no matter what it will be done on, there are more interesting research questions to ask about open source, secure operating systems, and heterogeneous environments than whether we can fix a few more bugs in BSD or Linux.
In fact, it seems to me that many hardware-supported information security mechanisms might end up having these two faces: on the one hand, you may be able to use them to protect your own data, on the other hand, people may be able to build an infrastructure around them that lets them control copying.
Ideas? Comments?
The SunBlade 1000 (an UltraSPARC III running at 500MHz) seems in the same ballpark as a high-end Intel or AMD processor, so I wouldn't get my hopes up too high for the SunBlade 100 (an UltraSPARC IIe running at 500MHz); it's probably a reasonable deal compared to PCs, but not great.
The really interesting thing is that that the SunBlade 100 is a 64bit machine for less than $1000.
We may be discussing the relative merits of Debian vs. RedHat at length, but in my opinion both are stellar compared to Sun's inconvenient administrative and packaging tools. Even if Sun were completely up to speed in those areas, there is still the issue that Solaris puts many files in different places from Linux (and BSD and SunOS, for that matter) and that getting and installing the latest GNU software on Solaris is still a lot more work than on Linux in my experience.
I believe the Debian UltraSPARC port is coming along but not quite complete yet. Anybody have more information? Can you get a basic Linux system with accelerated XFree86, GNU C/C++, Perl, and Python up on these things? What about Sun Java for Linux/SPARC? If the Linux kernel isn't up to speed for UltraSPARC, what about a RedHat Debian distribution built around the Solaris kernel?
I very much hope that the IEEE is a temporary aberration when it comes to on-line publishing, because a model in which a few on-line publishers can dictate on the basis of their market position what they pay content creators and charge subscribers is not desirable.
The problem with ACLs is that they provide such fine control that they lead to maintenance problems.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Yes, and ACLs are a good example of that.
See, and that's at the heart of the design issue. Many of the "limited" permissions you might construct with ACLs turn out to be equivalent to "root" permissions anyway; having ACLs gives you a false sense of security. Delegation of specific privileges generally only works reliably with very careful programmatic permission checking. That's why UNIX has setuid programs.
MacOS and MSWindows originally sacrificed flexibility in order to lower resource requirements. That's nice, but it is wrong to let them patent all sorts of features now that their platforms have caught up in terms of performance that used to be commonplace on high-end machines. (Incidentally, I don't think KDE or Gnome are much better in this regard than MacOS or MSWindows, which is too bad, since they had a chance to do a better job.)