It's not really necessary to ban insecure login protocols; what is needed is for schools not to provide them. Since schools generally provide at least email if not shell accounts, and usually provide the software to the students to give them access to these services (at least they did in '95 when I got my machine set up for the school network), they could just switch to requiring secure clients to access the provided services. Then, since the students are using secure clients for at least some applications, they are likely to only set up secure services if they set up servers (since that's what they are used to using clients for).
This entirely avoids the problem of enforcement and detection, and permits anonymous ftp and plaintext password logins to unimportant accounts.
Of course, the problem with Windows networking (and other unrestricted sharing protocols) remains, since people do that without prompting from the official school services. Probably the administration should scan for these and tell the owners that their computers have security problems.
The latest problem I'm seen with developing for windows is that it's easy to make your distribution destroy your users machines without meaning to. The broken way the windows handles dynamic libraries and updating them means that if you have a old or incompatible version of a library and distribute it with your program, users may install it and make their system unusable. This happened with a project I heard about recently, and really annoyed a lot of people who weren't expecting their friend's program to trash their system.
With Linux either you just tell your users to get the libraries they need if they don't have them, or you use a package management system, which works far better than the windows scheme.
They missed the compressed dictionary tree substring search algorithm, which is a very important one these days.
It takes a O(length of document) time and space preprocessing step, and then each query takes O(length of query) (i.e., it doesn't matter how long the document is for doing the searches).
In addition to being good for simple text searching, it's really good for searching DNA databases. When you've got 4 T of data, and want to find a 1 k sequence, it's really good if the time required doesn't depend on the size of the whole database.
The main actual objection is that it's likely to be implemented in software by a certain company, and their implementation is likely to be possible to activate automatically. Then you can have a virus which signs documents if you use your key while you have it.
What about a virus with a license that absolves the author from responsibility for damages which signs the license with the victem's key?
Key storage (even in memory) will be a major problem for Windows, even with a good implementation, because Windows doesn't have very good memory protection or system protection.
Ideally, the only approved implementation would be in specialized hardware which cannot be made to give up the private key, and will force the user to at least scroll though the entire text they sign. I would expect some PDA-type thing with a IO connector. Not that people couldn't sign with other devices, but the government would have warned them about the risks of using a software version or interface.
He has some good points, although he seems to be missing some things.
It is true that the vast majority of cool new ideas don't make it into implementstion and use. Witness the recent reaction to having a Python script in the Linux kernel distribution.
But he seems to have forgotten the details of the good old days he's talking about: computers didn't do all that much yet. A group working for a reasonable amount of time could make something more useful than they could pick up at the store. There wasn't so much previous work that would be wasted if they redesigned from scratch.
There are a lot of standards now, and it is true that an entirely new project will probably spend 90% of their work on complying with standards. But that only prohibits entirely new projects; starting from a unix implementation that supports all the relevant protocols, you can do new work in a reasonable time, and the result will actually be potentially useful.
It's not that hard to imagine a very innovative project which is designed to be a part of a unix-like operating system but take it in an entirely new direction. We may still be using a unix-like filesystem, but now it can have journalling. Our unix processes can have threads. Our X server can support OpenGL.
Significantly, a small team of developers who have read a good paper can sit down to implement it. They don't have to start from scratch, implementing every protocol ever specified, they can just get the latest Linux kernel, which supports them already. Then they can add just the section they're interested in.
It is not a problem that there are standards up to the level of an API for operating systems. There is enough flexibility in the API we have that there can be significantly different behavior on the other side, and, significantly, someone wanting to use this new behavior can easily understand how to do so, since it conforms to the API. The field of AI suffers greatly from this not being the case: there is no standard substructure that researchers can use to make their systems advance the field rather than giving it the same depth in a different direction.
At least at MIT, there is plenty of research in systems which is actually being implemented. The reason this is not obvious is that the outside world of corporations now gets all the computer press, so these projects don't seem as important as when most of the computers were in academia.
Incidentally, while Java is not perfect, it is more than just a fixed redesign of C++: in addition to better object orientation, it has type safety, a virtual machine, and garbage collection, all of which came out of academic research on the subject.
All in all, noticing the new work in systems research these days requires looking in more detail at systems which have progressed in significant ways, not just looking for things which look superficially different from established systems.
If an attacker knew what part of this data stream was the key, that could be a problem. But when you've got this thing running for years, it might as well be secret. You have to transmit the starting position and how you're using the key securely, but using this broadcast could let someone expand a relatively short key into a lot of digits to encrypt with without requiring much extra computation.
I would guess that these numbers form a really long one-time-pad. The agents using them pick a starting point and then XOR (or add mod 10) their message with the stream of digits. Then they only have to transmit their starting point in a complicated cipher. The agents only have to listen to the radio to get the sequence from their selected starting point, and home base either records the whole thing or has the script.
There might be an interesting pattern in the numbers if the random number generator is only pseudo-random, but I would guess they'd use a physical process instead of a mathematical one, given that the indend to send out digits for years on end.
This means that all applications must be decoupled from their interfaces, and that's nontrivial if possible at all.
It is likely to be impossible for existing applications to be thus decoupled retroactively, but I suspect that, with suitable specifications, new applications could reasonably be written decoupled from their interfaces.
The ideal interface would probably be a multiplexed text stream of some sort, where the user would send commands to the program and it would respond in one main virtual stream using additional data in other virtual streams. The data would conform to some content specification. In practice, nobody (except people debugging the program) would use the raw interface, but would instead use a front end which could be shared across applications which would render the various programs in a unified manner, and would be chosen (and configured) by the user.
The main problems I see are:
Coming up with a sufficiently general specification. Possibly something related to HTML would be good (I've written a program that used HTTPS as the interface, and that worked well), with suitable standards for other content types. There's still the program of creating the spec and keeping people from stuffing incompatible extensions in on one side or the other.
Handling applications which are mostly interfaces. For example, a wysiwyg word processor is actually a display for a markup language of some sort which can print it and has built-in commands to add particular bits of markup. It's unclear what (if anything) is not the user interface (i.e., would be the back end) in this case.
Also, applications with very specific sorts of interface necessarily attached. For example, the game of Go. There's a board on which players place pieces. It requires a great deal of imagination to come up with a text-only or voice-only interface, and it clearly would be impossible to specify Go in such a way that a front end that was not specifically for Go would present a good interface. (especially since the front end might be voice-only)
On the other hand... there are a couple of protocols suitable for playing Go on the internet. There are quite a few entirely different clients which speak these protocols (even to a local back end) and which look remarkably different, and some of the protocols make it possible (although not easy) to play with plain text, just using telnet. So maybe the problems are not insurmountable after all.
Sensible defaults and cross-application UIs
on
Suck On Skins And UI
·
· Score: 1
All applications ought to look and act the same.
Or rather, they should all look and act the same when a given person uses them. When somebody different uses them, they should probably be quite different, but still, all of the applications should be the same. Many people probably want them to all behave like Windows programs, for example, but I don't want any of them to behave that way.
Of course, most windows users probably want the windows look and feel, and most mac users probably want the mac look and feel, so it is a good approximation to use the platform's general UI as the default.
Skins combine the worst features of configurability: why would I want to download something to make my computer look and act unfamiliar? Why would I want to make each application behave differently?
On the other hand, it would be incredibly useful to be able to say, "Any time I am editing text, ^K cuts the rest of the line and appends it to a buffer I can retrieve with ^Y." And have this apply to my text editor, my mail reader, my web browser, my word processor, and even the word processor I have to use on Windows.
Of course, it would also mean that a Windows user could specify that all of their applications should behave like Windows, or, even better, wouldn't have to, since they'd get their computer with that as the default.
We don't need uniformity across systems. I'm actually really happy with a desktop that would totally baffle just about anyone else (I use Shift-Shift and Alt-Alt for various things, e.g.); I don't want other people to switch to my weird setup, not do I want to switch to another setup.
What we do need is uniformity across applications, so that when I run anything, I get an interface I like, and when anyone else runs something, they get their interface of choice.
We need to standardize on a way of specifying key bindings, menu layouts, widgets, etc. The thing that Windows does right (but MacOS did even better and sooner) is that all of the programs behave similarly. Now, if the layer of configurability is on the other side of the application boundary, so that the *user* gets to decide how everything will be instead of the *programmer* getting (or needing) to decide, we can have the benefit of this uniformity and also have extensive customization.
Re:PKI and other issues
on
SSH v. SRP
·
· Score: 2
SSH keeps track of the server public keys of sites you connect to and warns you strongly if the key has changed. Since the private key corresponding to the public key is used in the protocol, either the man in the middle is simply forwarding the traffic, which remains secure, or the server has been compromised, or the man in the middle is reporting a different public key for the server.
The initial connection is important-- you need to get the right server key the first time (and any time the server changes it). But in the usual case, you have an independent way of verifying that you're connected to the site you think you are in special circumstances.
Any project-management is difficult. Whether it be closed-source, open-source, or even one person working in their free time, there needs to be a percentage of time spent proportional to the size of the project on managing it; a very large project will require a lot of management even for the most cohesive and dedicated group.
On the other hand, the open-source community has a habit of not making projects that big. Rather than having an Operating System, there's a kernel, a library, a compiler, a set of file utilities, a shell, an X server, a window manager... the fact of having all of these parts as separate projects increases the amount to which pieces are made to fixed specifications and thus can be treated as separate projects. The open source community couldn't write Windows, but it wouldn't think to try: writing the Linux kernel and glibc and mozilla makes more sense (people work on what they find interesting, and depend on a reasonable subset of the community).
On the other hand, it is not likely that the feature sets of major projects will eventually be dictated by the demands of business users. We already have the habit of telling people, "if you want that feature, write it yourself." The Linux kernel only gets features that seem to be good to have, not features that people are asking for. RedHat and SuSE and Debian don't even get to say what goes into the official kernel-- if they want some feature, that's their own business and they have to do it themselves.
The way things are now, and the way they will probably continue to be is that the various projects make their results the best they can in the technical aspects, and other people work on usability.
You are probably correct that this considers all CSS decryption tools to be DeCSS. On the other hand, the injunction only prohibits the defendants from doing things with DeCSS. So they can't sell their DVD players, but Circuit City still can.
The biggest reason I support the variety of Linux distributions is that it means Linux can go mainstream and still be elitist. I run what it essentially a home-brew box these days. The last time I had a distribution was in '96, and I didn't even have it set up right then. I've fixed problems by getting new versions of programs and upgrading stuff as I felt the need for it.
I like the fact that RedHat is making it easy to install Linux and easy to get the programs you want. I also like it that Linus and the kernel hackers aren't working on this, and aren't interested in making Linux easier. There's a cutting edge of people doing cool stuff, and a trailing edge of people making the whole system usable, and the former don't take orders from the latter.
This is really important. There is not a single entity which is Linux, so there can be a Mainstream Linux and a Elitist Linux with no trouble. Even if there is the simplest interface to Linux which hides half of the cool features, I don't have to use it. There's nothing wrong with the possible existence of a Linux distribution that doesn't run any special services and is a single-user machine; sure, I'd find it annoyingly mundane, but I'd just not use it.
I'd actually like there to be a non-server-class Linux distribution. I think that would increase the amount that Linux would compete for the desktop, and I think that you'd see more hardware and software support which even the elitists can use.
I use fvwm primarily mouselessly. I have all of the window manager commands set to be keyboard accessible, and have them within reach by using strange key combinations. fvwn lets you bind menus and such to combinations like left-alt right-alt and such, which I have done (Alt-Alt both ways, some Shift-shift and shift-alt).
Mainly I use the mouse to use netscape (because I don't have a mouse-free graphical browser) and to do window manager stuff while using netscape, since my hand in already on the mouse. The only thing I find annoying about this is moving windows, which takes a bunch of key strokes to move across the screen, but can't really be helped.
What this implies is students being bullied have a responsibility to keep it from being sufficiently common to be considered notable. Previously, going to school officials every time you got beat up was considered being a wimp. But with this, if you don't get the bullying stopped, you may be considered psychopathic. It's not that you can't take the pain, it's that if you do, you may be thrown out of school.
Of course, any school administrator who uses this bit of profiling must know about a pattern of attacks on the student. Presumably, this could not continue if the administrator were actually trying to stop it, and so the administrator must be ignoring the problem. And last I heard, being an accessorry to assult is a serious crime, one that would carry very serious penalties if you were convicted of many counts of it.
If you're being bullied, call your school administrators. If this doesn't help, call the police. If this doesn't help, call the ACLU. If you don't, you may be considered a criminal.
TeX actually doesn't require you to do anything much to put up a few characters-- just put "\bye" at the end of the document. The other stuff is for making the page sizes and format the way you'd like, and you can set those up once (or steal somebody else's) and just use that.
You need the more complicated stuff for tables and math symbols, but it's on the easy side for putting math in a document.
I had a hard time getting teTeX installed correctly, and somehow managed to learn how to use TeX before I had managed to set it up. Generally, I just write in a text editor and then proofread the formatted text. I find I make about a mistake/page which I don't see typing up a math problem.
Of course, you can make TeX files arbitrarily complex, and it includes a massive scripting language, but you can just ignore the details and use other people's macros.
Also, IMHO, it produces the nicest-looking and most readable output of the publishing systems I've seen.
I've been a fan of Microsoft since way back when they made a nice solid mouse with a simple and clear API that they documented in a readable manual.
Some stupid software company seems to have been releasing crappy operating systems under their name since then, though. I think it's probably ruined their reputation, unfortunately.
Actually, breaking codes that don't rely on computational power is quite fun. Games magazine has had substitution ciphers each month practically forever.
I had a problem set which involved two texts encrypted with the same one-time-pad, where we were supposed to recover the texts. It was remarkably fun in the same way that Games tends to be fun.
I find the most significant part is not installing Linux but in playing around with it once it's running. Getting new stuff to work will invariably make you learn more about your system, and teach you what is worth remembering. If you're already interested in how the OS actually works, you'll only become more so as it becomes relevant to actually using the system.
I'm glad you discovered that Linux is actually user-supported. I'm curious as to how you managed not to already know this. There seem to be plenty of fora that the users who help people know about, but the people who need help seem less likely to know about them. How did we not get you to go to your friend right from the start and ask for help getting stuff set up?
The thing that makes this flaw interesting is that, unlike their other flaws, it is not in the code which protects the user from other people, it's in the code that protects Windows itself from users. The hole has an effect similar to breaking copy protection, except that instead of letting the cracker copy the program, it lets them install additional cryptographic software. This ability is considered really bad by the government, and software which has it may not, in general, be exported.
Usually it's just customers who are affected by MS security holes, and MS doesn't have to care about customers. But in this case, it's the government that's affected, and MS does have to care. I expect a major press release and a fix pretty soon.
The simplest would be to require the keys to be signed by MS, so random people can't just swap them.
What I heard when the whole thing with Compuserve first came out was that Compuserve had thought the algorithm was in the public domain because it had been published by the inventor without a patent pending notice. Also, it turned out that he hadn't applied for the patent until too much time had passed after he had published the algorithm for the patent to actually be valid.
I haven't heard any justification of the patent on these grounds; I don't think UNISYS or anyone has actually had to defend their patent claims, since they haven't actually sued anyone over it. I had thought that UNISYS was failing to do anything about people violation the patent because they knew if they got into a case, the patent wouldn't hold up and the people they'd licensed it to would be able to get their money back.
C++ isn't as good a language as Java. It's a generation behind and, unlike C, isn't the ultimate in its particular style. Therefore, programmers will eventually want to move on to the next language.
Visual design tools are merely acknowledging that the proper way to lay out a GUI is graphical, in much the same way that creating images is a lot easier graphically. With them, it's easy to slap an interface onto whatever you've got. This means that dull stuff as well as cool stuff has a GUI.
The case where this isn't good is when you care about framerate on a local display, you're generating stuff on the fly in a method that video cards can do for you, and you're pumping out a lot of data.
To me it sounds like this situation is one in which the user is going to be focused pretty heavily on what this program is generating. In this case, you don't really want other windows onscreen, so it's not just the overhead of X you don't want, it's also the functionality.
I noticed something interesting in this article that I hadn't noticed before. This guy is configuring his network connection. He goes through the GUI setup utility, but then gets stuck. He reads the documentation, and then realizes that he's going to have to edit configuration files with a text editor. *This* is where he decides it's difficult.
So why is this? He's got the documentation, he's already been typing stuff, so what's the big deal about using a text editor?
I think the next important area for documentation is going to be setting up text editors to document what you're trying to configure. If there was documentation which specified the format of the configuration file, and you could lock the text editor into a mode where it formatted stuff to work for a given sort of config file, and it would put the documentation with the stuff you're actually editing, it would basically be a GUI configuration device. And it wouldn't messy with your plain text configuration files, and the configuration clue would seep into the clueless user.
Slashdot Mirror
It's not really necessary to ban insecure login protocols; what is needed is for schools not to provide them. Since schools generally provide at least email if not shell accounts, and usually provide the software to the students to give them access to these services (at least they did in '95 when I got my machine set up for the school network), they could just switch to requiring secure clients to access the provided services. Then, since the students are using secure clients for at least some applications, they are likely to only set up secure services if they set up servers (since that's what they are used to using clients for).
This entirely avoids the problem of enforcement and detection, and permits anonymous ftp and plaintext password logins to unimportant accounts.
Of course, the problem with Windows networking (and other unrestricted sharing protocols) remains, since people do that without prompting from the official school services. Probably the administration should scan for these and tell the owners that their computers have security problems.
The latest problem I'm seen with developing for windows is that it's easy to make your distribution destroy your users machines without meaning to. The broken way the windows handles dynamic libraries and updating them means that if you have a old or incompatible version of a library and distribute it with your program, users may install it and make their system unusable. This happened with a project I heard about recently, and really annoyed a lot of people who weren't expecting their friend's program to trash their system.
With Linux either you just tell your users to get the libraries they need if they don't have them, or you use a package management system, which works far better than the windows scheme.
They missed the compressed dictionary tree substring search algorithm, which is a very important one these days.
It takes a O(length of document) time and space preprocessing step, and then each query takes O(length of query) (i.e., it doesn't matter how long the document is for doing the searches).
In addition to being good for simple text searching, it's really good for searching DNA databases. When you've got 4 T of data, and want to find a 1 k sequence, it's really good if the time required doesn't depend on the size of the whole database.
The main actual objection is that it's likely to be implemented in software by a certain company, and their implementation is likely to be possible to activate automatically. Then you can have a virus which signs documents if you use your key while you have it.
What about a virus with a license that absolves the author from responsibility for damages which signs the license with the victem's key?
Key storage (even in memory) will be a major problem for Windows, even with a good implementation, because Windows doesn't have very good memory protection or system protection.
Ideally, the only approved implementation would be in specialized hardware which cannot be made to give up the private key, and will force the user to at least scroll though the entire text they sign. I would expect some PDA-type thing with a IO connector. Not that people couldn't sign with other devices, but the government would have warned them about the risks of using a software version or interface.
He has some good points, although he seems to be missing some things.
It is true that the vast majority of cool new ideas don't make it into implementstion and use. Witness the recent reaction to having a Python script in the Linux kernel distribution.
But he seems to have forgotten the details of the good old days he's talking about: computers didn't do all that much yet. A group working for a reasonable amount of time could make something more useful than they could pick up at the store. There wasn't so much previous work that would be wasted if they redesigned from scratch.
There are a lot of standards now, and it is true that an entirely new project will probably spend 90% of their work on complying with standards. But that only prohibits entirely new projects; starting from a unix implementation that supports all the relevant protocols, you can do new work in a reasonable time, and the result will actually be potentially useful.
It's not that hard to imagine a very innovative project which is designed to be a part of a unix-like operating system but take it in an entirely new direction. We may still be using a unix-like filesystem, but now it can have journalling. Our unix processes can have threads. Our X server can support OpenGL.
Significantly, a small team of developers who have read a good paper can sit down to implement it. They don't have to start from scratch, implementing every protocol ever specified, they can just get the latest Linux kernel, which supports them already. Then they can add just the section they're interested in.
It is not a problem that there are standards up to the level of an API for operating systems. There is enough flexibility in the API we have that there can be significantly different behavior on the other side, and, significantly, someone wanting to use this new behavior can easily understand how to do so, since it conforms to the API. The field of AI suffers greatly from this not being the case: there is no standard substructure that researchers can use to make their systems advance the field rather than giving it the same depth in a different direction.
At least at MIT, there is plenty of research in systems which is actually being implemented. The reason this is not obvious is that the outside world of corporations now gets all the computer press, so these projects don't seem as important as when most of the computers were in academia.
Incidentally, while Java is not perfect, it is more than just a fixed redesign of C++: in addition to better object orientation, it has type safety, a virtual machine, and garbage collection, all of which came out of academic research on the subject.
All in all, noticing the new work in systems research these days requires looking in more detail at systems which have progressed in significant ways, not just looking for things which look superficially different from established systems.
If an attacker knew what part of this data stream was the key, that could be a problem. But when you've got this thing running for years, it might as well be secret. You have to transmit the starting position and how you're using the key securely, but using this broadcast could let someone expand a relatively short key into a lot of digits to encrypt with without requiring much extra computation.
I would guess that these numbers form a really long one-time-pad. The agents using them pick a starting point and then XOR (or add mod 10) their message with the stream of digits. Then they only have to transmit their starting point in a complicated cipher. The agents only have to listen to the radio to get the sequence from their selected starting point, and home base either records the whole thing or has the script.
There might be an interesting pattern in the numbers if the random number generator is only pseudo-random, but I would guess they'd use a physical process instead of a mathematical one, given that the indend to send out digits for years on end.
This means that all applications must be decoupled from their interfaces, and that's nontrivial if possible at all.
It is likely to be impossible for existing applications to be thus decoupled retroactively, but I suspect that, with suitable specifications, new applications could reasonably be written decoupled from their interfaces.
The ideal interface would probably be a multiplexed text stream of some sort, where the user would send commands to the program and it would respond in one main virtual stream using additional data in other virtual streams. The data would conform to some content specification. In practice, nobody (except people debugging the program) would use the raw interface, but would instead use a front end which could be shared across applications which would render the various programs in a unified manner, and would be chosen (and configured) by the user.
The main problems I see are:
On the other hand... there are a couple of protocols suitable for playing Go on the internet. There are quite a few entirely different clients which speak these protocols (even to a local back end) and which look remarkably different, and some of the protocols make it possible (although not easy) to play with plain text, just using telnet. So maybe the problems are not insurmountable after all.
All applications ought to look and act the same.
Or rather, they should all look and act the same when a given person uses them. When somebody different uses them, they should probably be quite different, but still, all of the applications should be the same. Many people probably want them to all behave like Windows programs, for example, but I don't want any of them to behave that way.
Of course, most windows users probably want the windows look and feel, and most mac users probably want the mac look and feel, so it is a good approximation to use the platform's general UI as the default.
Skins combine the worst features of configurability: why would I want to download something to make my computer look and act unfamiliar? Why would I want to make each application behave differently?
On the other hand, it would be incredibly useful to be able to say, "Any time I am editing text, ^K cuts the rest of the line and appends it to a buffer I can retrieve with ^Y." And have this apply to my text editor, my mail reader, my web browser, my word processor, and even the word processor I have to use on Windows.
Of course, it would also mean that a Windows user could specify that all of their applications should behave like Windows, or, even better, wouldn't have to, since they'd get their computer with that as the default.
We don't need uniformity across systems. I'm actually really happy with a desktop that would totally baffle just about anyone else (I use Shift-Shift and Alt-Alt for various things, e.g.); I don't want other people to switch to my weird setup, not do I want to switch to another setup.
What we do need is uniformity across applications, so that when I run anything, I get an interface I like, and when anyone else runs something, they get their interface of choice.
We need to standardize on a way of specifying key bindings, menu layouts, widgets, etc. The thing that Windows does right (but MacOS did even better and sooner) is that all of the programs behave similarly. Now, if the layer of configurability is on the other side of the application boundary, so that the *user* gets to decide how everything will be instead of the *programmer* getting (or needing) to decide, we can have the benefit of this uniformity and also have extensive customization.
SSH keeps track of the server public keys of sites you connect to and warns you strongly if the key has changed. Since the private key corresponding to the public key is used in the protocol, either the man in the middle is simply forwarding the traffic, which remains secure, or the server has been compromised, or the man in the middle is reporting a different public key for the server.
The initial connection is important-- you need to get the right server key the first time (and any time the server changes it). But in the usual case, you have an independent way of verifying that you're connected to the site you think you are in special circumstances.
Any project-management is difficult. Whether it be closed-source, open-source, or even one person working in their free time, there needs to be a percentage of time spent proportional to the size of the project on managing it; a very large project will require a lot of management even for the most cohesive and dedicated group.
On the other hand, the open-source community has a habit of not making projects that big. Rather than having an Operating System, there's a kernel, a library, a compiler, a set of file utilities, a shell, an X server, a window manager... the fact of having all of these parts as separate projects increases the amount to which pieces are made to fixed specifications and thus can be treated as separate projects. The open source community couldn't write Windows, but it wouldn't think to try: writing the Linux kernel and glibc and mozilla makes more sense (people work on what they find interesting, and depend on a reasonable subset of the community).
On the other hand, it is not likely that the feature sets of major projects will eventually be dictated by the demands of business users. We already have the habit of telling people, "if you want that feature, write it yourself." The Linux kernel only gets features that seem to be good to have, not features that people are asking for. RedHat and SuSE and Debian don't even get to say what goes into the official kernel-- if they want some feature, that's their own business and they have to do it themselves.
The way things are now, and the way they will probably continue to be is that the various projects make their results the best they can in the technical aspects, and other people work on usability.
You are probably correct that this considers all CSS decryption tools to be DeCSS. On the other hand, the injunction only prohibits the defendants from doing things with DeCSS. So they can't sell their DVD players, but Circuit City still can.
The biggest reason I support the variety of Linux distributions is that it means Linux can go mainstream and still be elitist. I run what it essentially a home-brew box these days. The last time I had a distribution was in '96, and I didn't even have it set up right then. I've fixed problems by getting new versions of programs and upgrading stuff as I felt the need for it.
I like the fact that RedHat is making it easy to install Linux and easy to get the programs you want. I also like it that Linus and the kernel hackers aren't working on this, and aren't interested in making Linux easier. There's a cutting edge of people doing cool stuff, and a trailing edge of people making the whole system usable, and the former don't take orders from the latter.
This is really important. There is not a single entity which is Linux, so there can be a Mainstream Linux and a Elitist Linux with no trouble. Even if there is the simplest interface to Linux which hides half of the cool features, I don't have to use it. There's nothing wrong with the possible existence of a Linux distribution that doesn't run any special services and is a single-user machine; sure, I'd find it annoyingly mundane, but I'd just not use it.
I'd actually like there to be a non-server-class Linux distribution. I think that would increase the amount that Linux would compete for the desktop, and I think that you'd see more hardware and software support which even the elitists can use.
I use fvwm primarily mouselessly. I have all of the window manager commands set to be keyboard accessible, and have them within reach by using strange key combinations. fvwn lets you bind menus and such to combinations like left-alt right-alt and such, which I have done (Alt-Alt both ways, some Shift-shift and shift-alt).
Mainly I use the mouse to use netscape (because I don't have a mouse-free graphical browser) and to do window manager stuff while using netscape, since my hand in already on the mouse. The only thing I find annoying about this is moving windows, which takes a bunch of key strokes to move across the screen, but can't really be helped.
What this implies is students being bullied have a responsibility to keep it from being sufficiently common to be considered notable. Previously, going to school officials every time you got beat up was considered being a wimp. But with this, if you don't get the bullying stopped, you may be considered psychopathic. It's not that you can't take the pain, it's that if you do, you may be thrown out of school.
Of course, any school administrator who uses this bit of profiling must know about a pattern of attacks on the student. Presumably, this could not continue if the administrator were actually trying to stop it, and so the administrator must be ignoring the problem. And last I heard, being an accessorry to assult is a serious crime, one that would carry very serious penalties if you were convicted of many counts of it.
If you're being bullied, call your school administrators. If this doesn't help, call the police. If this doesn't help, call the ACLU. If you don't, you may be considered a criminal.
TeX actually doesn't require you to do anything much to put up a few characters-- just put "\bye" at the end of the document. The other stuff is for making the page sizes and format the way you'd like, and you can set those up once (or steal somebody else's) and just use that.
You need the more complicated stuff for tables and math symbols, but it's on the easy side for putting math in a document.
I had a hard time getting teTeX installed correctly, and somehow managed to learn how to use TeX before I had managed to set it up. Generally, I just write in a text editor and then proofread the formatted text. I find I make about a mistake/page which I don't see typing up a math problem.
Of course, you can make TeX files arbitrarily complex, and it includes a massive scripting language, but you can just ignore the details and use other people's macros.
Also, IMHO, it produces the nicest-looking and most readable output of the publishing systems I've seen.
I've been a fan of Microsoft since way back when they made a nice solid mouse with a simple and clear API that they documented in a readable manual.
Some stupid software company seems to have been releasing crappy operating systems under their name since then, though. I think it's probably ruined their reputation, unfortunately.
Actually, breaking codes that don't rely on computational power is quite fun. Games magazine has had substitution ciphers each month practically forever.
I had a problem set which involved two texts encrypted with the same one-time-pad, where we were supposed to recover the texts. It was remarkably fun in the same way that Games tends to be fun.
I find the most significant part is not installing Linux but in playing around with it once it's running. Getting new stuff to work will invariably make you learn more about your system, and teach you what is worth remembering. If you're already interested in how the OS actually works, you'll only become more so as it becomes relevant to actually using the system.
I'm glad you discovered that Linux is actually user-supported. I'm curious as to how you managed not to already know this. There seem to be plenty of fora that the users who help people know about, but the people who need help seem less likely to know about them. How did we not get you to go to your friend right from the start and ask for help getting stuff set up?
The thing that makes this flaw interesting is that, unlike their other flaws, it is not in the code which protects the user from other people, it's in the code that protects Windows itself from users. The hole has an effect similar to breaking copy protection, except that instead of letting the cracker copy the program, it lets them install additional cryptographic software. This ability is considered really bad by the government, and software which has it may not, in general, be exported.
Usually it's just customers who are affected by MS security holes, and MS doesn't have to care about customers. But in this case, it's the government that's affected, and MS does have to care. I expect a major press release and a fix pretty soon.
The simplest would be to require the keys to be signed by MS, so random people can't just swap them.
What I heard when the whole thing with Compuserve first came out was that Compuserve had thought the algorithm was in the public domain because it had been published by the inventor without a patent pending notice. Also, it turned out that he hadn't applied for the patent until too much time had passed after he had published the algorithm for the patent to actually be valid.
I haven't heard any justification of the patent on these grounds; I don't think UNISYS or anyone has actually had to defend their patent claims, since they haven't actually sued anyone over it. I had thought that UNISYS was failing to do anything about people violation the patent because they knew if they got into a case, the patent wouldn't hold up and the people they'd licensed it to would be able to get their money back.
C++ isn't as good a language as Java. It's a generation behind and, unlike C, isn't the ultimate in its particular style. Therefore, programmers will eventually want to move on to the next language.
Visual design tools are merely acknowledging that the proper way to lay out a GUI is graphical, in much the same way that creating images is a lot easier graphically. With them, it's easy to slap an interface onto whatever you've got. This means that dull stuff as well as cool stuff has a GUI.
The case where this isn't good is when you care about framerate on a local display, you're generating stuff on the fly in a method that video cards can do for you, and you're pumping out a lot of data.
To me it sounds like this situation is one in which the user is going to be focused pretty heavily on what this program is generating. In this case, you don't really want other windows onscreen, so it's not just the overhead of X you don't want, it's also the functionality.
I noticed something interesting in this article that I hadn't noticed before. This guy is configuring his network connection. He goes through the GUI setup utility, but then gets stuck. He reads the documentation, and then realizes that he's going to have to edit configuration files with a text editor. *This* is where he decides it's difficult.
So why is this? He's got the documentation, he's already been typing stuff, so what's the big deal about using a text editor?
I think the next important area for documentation is going to be setting up text editors to document what you're trying to configure. If there was documentation which specified the format of the configuration file, and you could lock the text editor into a mode where it formatted stuff to work for a given sort of config file, and it would put the documentation with the stuff you're actually editing, it would basically be a GUI configuration device. And it wouldn't messy with your plain text configuration files, and the configuration clue would seep into the clueless user.