I'm cringing at a few of the inaccuracies!
on
Matt Welsh on NPR
·
· Score: 2
Call me nitpicky, but accuracy is important.
- UNIX (in any form that remotely resembles it as we know it now) does not date back to the 60's, but rather early 70's. The very earliest assembly language work started around 1969, when Ken had yet to develop basics like an assembler and editor that would run on the target host, not to mention a higher level language. C wasn't developed until around 1973 or 1974. You wouldn't want to be running most of the operating systems that actually date back to the 60's.:)
- The GPL does not require you to release modifications. Only if you do release, you must not do so in binary only form. So it's not accurate to say that ``you have to share'', but that ``you can't release the modified software in executable form only''.
- Linux is not just for PC's.
- OpenBSD is not ``security through obscurity''. Matt says that he doesn't want to incite a religious flamewar and then turns around to say that. What about the fact that a bunch of hackers did a line by line security audit that supposedly took a number of years? To use a derogatory term like ``security through obscurity'' is an insult to these people. Sure, there may be an element of obscurity because OpenBSD isn't that popular, but that's no excuse for FUD. Matt blew a perfectly good opportunity to use OpenBSD as an example of how open source code allows people to increase their confidence in systems security.
It's a fair challenge. Obviously they had to be confident that the competitor lacks key features. Database optimization is not all about having a higher -O flag on your compiler.
I wouldn't say that they weren't risking anything. They gave Microsoft three months to catch up, during which time they could have hacked out materialized views---or found someone who could do it for a million bucks, such as some moonlighting Oracle employee.;)
Moreover, the query doesn't seem to be contrived at all. It's a simple, run of the mill query, applied to a huge database. The Oracle feature which makes the query run fast seems to be an actual real-world advantage, not just some benchmark fodder.
So why can't M$ get it going on the same platform? Oops, I forgot. They have yet to learn to overcome their fear of bytesex. Every version of Windows requires a little endian processor, that's how incompetent they are. Even CE, which runs on RISC platforms like MIPS and Strongarm (which are bi).
Man, Thompson and Ritchie give them the freaking programming language, show them how it's done, give them the freaking programming language and they still don't get it nearly 30 years later.:)
Fallacy: if you needed compilers to make compilers, we would still be programming by plugging wires into sockets.
The first compiler for the language B had to be written in PDP-7 assembly language, and then re-written in B. As the language was improved, the improvements were used in its source code.
It took a mere four or five years for Thompson and Ritchie to go from nothing to C+UNIX.
Of course, having existing tools means that you don't have to go through the pain of bootstrapping yourself from nothing! But there is a fine semantic divide between ``difficult'' and ``impossible''.
Also, I did mention that early Linux was compiled with a Borland compiler, so your point about free software needing commercial tools at the outset is somewhat redundant.
That is an interesting point. The next logical step would be a free compiler and libraries to support these apps. Free Pascal seems like step in that direction.
I only *hope*, rather than demand, that people choose not to give up freedom for whatever advantage they hope to gain.
By the way, why is it that your customers depend on you and on Inprise to provide the freedom to choose between NT and Linux? If you didn't provide the choice, could they go to someone else? Some freedom they have there.;)
Nor a bad thing. It's just another piece of proprietary software that I'm not interested in running on my freedom platform. I hope you won't be seduced either.
Linux hasn't needed Borland since the day it became powerful enough to run GCC and serve as its own development platform.
Some of you are euphoric every time some commercial vendor offers a piece of ``support'' for Linux, because it means that the popularity of your favorite operating system is increasing. So you rejoice at the popularity increase even if you don't plan to use the newly ported product.
Some, like me, would use a freedom platform even if it wasn't popular, and would use freedom software even if it wasn't as good as a proprietary alternative in terms of convenience or performance or other measures. How about you?
If the kid loses his card, he ceases to exist. Other kids will walk by him or her, acting as if he or she were not there. The glances of others will seem to shift and focus on objects beyond the individual, never making any contact, as though the individual were invisible.
Actually, the correct techie pluralization of box is ``boxen'' not ``boxes''. So you can rest assured that these people are utterly clueless, and don't have to worry about what this world is coming to.
It makes sense, because it places all of the control on the server side, giving the schools central control over everything.
This is nothing new; universities have relied on labs of XWindow terminals for years and years, which are basically NC's. Again, the advantage there is centralization of resources and security---but most of all, control over the students' use of the equipment.
Interix (previously OpenNT) is a way for developers to ignore proprietary Windows interfaces and continue developing UNIX and POSIX software. They are not fully in the Windows trap because they can easily get out.
Microsoft wants all development to take place using its proprietary interfaces. It's obvious that they bought Interix because they want control. They probably want to exert pressure on Interix users to migrate to real Windoze.
I also predict that Microsoft will maim or kill the project. Whatever the outcome, they have no real incentive to provide a *quality* UNIX layer on NT. They want to be able to tell the customer---look, if you wanna write a real Windoze application that performs and scales, be sensible and use the real thing! Install Visual C++ and start calling Win32!
Now, a historic observation, for what it may be worth: all UNIX emulation layers in the past have bit the dust. Only real kernels have survived. The appearance of an emulation layer has also historically sounded the death knell of the host platform---recall VMS, Apollo Domain/OS, various mainframe platforms...
Cable modems are broadband devices. They use two channels: one for sending and one for receiving. It's possible for the cable company to allocate many pairs of channels on the same cable: in other words, do frequency division multiplexing.
So you are not necessarily on the same LAN with everyone else who is on the same wire as you, and the cable does not necessarily have to be split into segments.
The question is, what does it take for a given cable company to start allocating more channels? I suspect that they just cram as many users onto the same pair of channels as they can, and won't allocate any more until enough people complain.
What's so heart attack inducing about being able to boot Linux from another OS and sharing a filesystem partition between the two? It's been done for years, starting with DOS. You can use LOADLIN to boot Linux from DOS and thanks to the UMSDOS file system, you can have a root partition (with long file names and other comforts) based on a DOS filesystem.
This isn't Linux running ``under'' Windows as an application. It's merely Linux sharing a filesystem with Windows. You still have to reboot to the Linux kernel. Thus I suspect that you are going to, for instance, find it rather inconvenient to interoperate gnupg with your Windows e-mail program.
Any C programmer worth his salt can figure out how to write a module by looking at other modules and the Apache source code.
What kind of hand holding is next? Apache Module Wizard integrated into bash?;)
Let's face it; most computer books are written purely for profit. Particularly ones about dreary, passionless, narrowly-defined topics like writing extensions to a particular application.
From an instruction set architectural point of view, the eZ80 sounds roughly about as powerful as a MC68000, which was introduced in 1979 and was the first member of its family. Zilog has been playing catch up ever since. First the Z8000, then the Z80000. The pinout of the eZ80 vaguely resembles an 68008. Eight data lines, Twenty four address lines (Okay, so the 68K doesn't have A0, but rather two decoded strobes: UDS and LDS).
As for the instruction set; the Z8000 and Z80000 are rather obscure architectures. According to the eZ80 PDF spec, Z80 programming is supported in some kind of virtual machine mode, probably similar to V86 on 80x86 processors. From what I gather is that you run Z80 code in a 64 kilobyte ``sandbox''. Blech! Whatever abundance of Z80 programming talent may be out there, if I'm to believe you, is only directly applicable to this lobotomized mode. I'm guessing, but the full mode likely has an instruction set that is compatible with the 32 bit Z80000, so you want to be coding in that language.
(You know, a lot of people know 8086 programming! But what does that have to do with 32 bit 80386? Would you build on a 80386 on the justification that you can easily find DOS programmers who can hack 8086 code? Oops.)
It's likely that more people know 68K programming than Z80*000* programming. 68K programming hasn't changed much in twenty years, in the sense that if all you know is the original Motorola instruction set (which is pretty darn nice as far as these things go), you can still make fairly good use of any of the family members, unconstrained by address space or register size issues. That is not the case with these awful 4004 descendants, which, despite maintaining measures of backward compatibility, have undergone radical instruction set transformations.
Anyway, you'd probably want to program a 32 bit processor in a higher level language---so ultimately who cares how nice the instruction set is from the programmer's perspective? You can pick up a new machine language on week's notice if you need to; you just need a solid architecture reference manual.
As for the TCP/IP stack---big deal. All you need is a C compiler and some time to port an existing stack. I suspect that these things are a lot easier to come by for a 68K system, than for a Z80* system. (Here is a question: for one thing, is GCC currently targetted for Z80K?)
But I'm all for diversity: let me know when they have Linux or *BSD running on some Z80* box.;)
The eZ80 might offer an upgrade path for current Z80 users, but I don't see how it fits into new product design. (But couldn't a Z80 emulator also take care of some of these users?)
Why would anyone use this over, say, some Motorola 68K family processor or some RISC thing?
Looked at in the best light, the license is probably intended cover any Corel proprietary content that may be in the distribution. Obviously, the beta test license cannot conceivably apply to any material that is under the GPL, so you can ignore the license with respect to those components that fall under the GPL (or other licenses incompatible with Corel's).
The only gripe I have is that their license doesn't make it clear what is and what is not covered. Newbies might think that it covers every included item.
So this could be just a case of innocent misrepresentation. My guess is that someone in the company who is vaguely clueless about free software just applied some ``standard'' beta test licensing boiler-plate.
Encryption is a technological protection, yes. But what if you are told that its use is against policy? Remember, you are dealing with assholes who are hell-bent on monitoring everything, who can spin your use of encryption into a policy violation.
Encrypting your e-mail will prevent your boss (or sysadmin or whoever else) from reading it. But it won't prevent them from detecting that you are encrypting your e-mail.
E-mail encryption is sensible and it should be used for privacy regardless of the nature of your workplace; it is not, however, protection against workplace oppression. The protection against that is to either somehow change the workplace or just leave.
Firstly, the greatest falsehood in the essay is that it equates UNIX with Linux. Because Linux is a UNIX-like system, anything that affects the position of UNIX in the academic environment is also a threat to Linux. This is false; the real tension here is between open source free software and closed-source proprietary software. Both Windows NT and commercial UNIX fall into one camp when we view things this way. In the face of open source competition in the academic arena, not only Microsoft should be cutting deals, but so should vendors of proprietary UNIX.
Secondly, it is hard to believe that computer science and engineering academics could be persuaded to dump their True opreating systems (whatever those are) in favor of some garbage from Redmond. That is just not going to happen.
Another insinuated falsehood is that Linux has always been accepted in academic environments, and it was accepted purely because it is UNIX-like, and that it is very widely accepted by everyone in all computer science departments everywhere. Linux has flourished in the academic environments *in spite* of commercial UNIX variants. It was perhaps most used among undergraduates, at least initially. It was a long time before Linux made its way into departments, by sneaky routes not unlike those that it has taken in the corporate arena. Many old timer faculty members would scoff at Linux, being BSD freaks or commercial UNIX die-hards. It was (and *is*) hard enough to convince the academics that Linux is any good! Good luck trying to push NT on these people. It's not like all of computer science went crazy over Linux overnight. Undergraduates flocked to Linux because it gave them a good development platform that was compatible with the systems at school.
This brings me to my final point. Yes, to some extent, Linux did become popular in the university environment among computer science and engineering undergraduates because it provided students with a familiar enviroment. Students could perform computing assignments and then easily back port them to the UNIX machines at school. So it would appear that if the school gradually converts to a non-UNIX operating system, this advantage of Linux will disappear. That much I can buy; what I have a problem with is the logic of the next inference: namely that Linux is somehow endangered by this! Truth is, the students who depend on Linux to provide a familiar homework environment are not particularly significant to the Linux movement. At least, not any more! Linux has a much broader base of users now. Secondly, such users do not contribute to Linux; they are usually very junior programmers. Many of them dump Linux when it is no longer needed for doing homework, in order to make room for Windows games on their hard drives.;) Those students who are capable of contributing to a sophisticated open source project, an are motivated to do so, will do so regardless of what hell breaks loose at their school.
In short, I do not buy the view that Linux requires broad, grass-roots support in academia everywhere in order to survive. For that matter, I don't think that it *ever* did require that support, nor did it have that support, and that it has flourished in spite of *opposition* in academic circles as well as corporate environments---the only difference being that there is less UNIX ignorance in academia, which is a two-edged sword (less UNIX ignorance == more UNIX arrogance). I also don't think that the operating systems choosen by computer science or engineering academics have all that much impact on the real world. Otherwise you would see a heck of a lot more UNIX everywhere and far less Windows. The academics, along with their UNIX boxes, could all disappear overnight and it wouldn't make a difference to the future of Linux, nor to the future of anything.
What about office workers who are not ``technologically savvy''? Not everyone knows enough to look for and disable such a thing. Ignoring that, there could be nevertheless hidden difficulties behind trying to stop something like this. And not all the difficulties are necessarily technological.
If the employer is running software like this one everyone's workstation as a matter of policy, then by disabling it, you are violating company policy. If you get caught trying to disable the software, you could be disciplined or fired. It would be trivial to design monitoring softwarethat cannot be simply turned off without detection. For example, the software could periodically respond to special pings from a central server. Hacking up software to fake the responses could be a major challenge depending on how the program is constructed. If there is some serious crypto authentication, it would have to be reverse engineered and faithfully reproduced in the impostor program. Most people would have to wait for some hacker group to release such an ``anti-big-brother'' impostor.
Another problem is, it would seem suspicious if nothing is being recorded by the monitoring program. You would have to arrange for your impostor program to provide some sensible looking activity record while you conduct personal business. Otherwise you would have to explain the idle periods---and what if the monitoring is being used to detect idle workers as well as ones who are using the equipment for personal use?
A third problem is that even though you stop keyboard monitoring, your employer can still snoop the network. Presumably, any interactions you have with the Internet go through the company's routers. The boss doesn't necessarily need a tedious record of your keystrokes; just some software that can monitor TCP streams and other data. By tapping TCP streams, it should be possible to recover telnet sessions, FTP transfers, ICQ or IRC chats, Usenet reads and posts, etc. This is kind of spying is probably a lot more useful than having some keystroke record. (Of course, one could use an encrypting proxy system, but that alone could draw suspicion.)
I don't think that there is any real technological protection against this. Any such measures treat the symptom rather than the disease anyway! You have to treat the disease. If you happen to fall into such a predicament, organize with other users who are in the same boat, and let the corporation know that you won't take the spying. In other words, the classic organized labor solution to the problem of worker oppression.
Failing that, terrorist tactics might work. The spying has to be implemented by another employee. Simply threaten to, in the parking lot, break the legs of anyone who supports the company's oppressive measures. Distribute an anonymous flyer which threatens to blow up the premises if the spying isn't put to an end by a certain date. Phone in bomb threats. Etc.
As the subject says. The STL is a component of the C++ library standard. The standard specifies what is in the headers; the syntax and semantics of the objects (as well as intended asymptotic running times to somewhat constrain the implementation).
Several open source implementations of the STL are floating around; the best known one is perhaps the one from SGI. The one used by Microsoft was done by P. J. Plauger.
I suspect that the article is talking about very high level cognitive processes. But it's clear that heck of a lot of parallel preprocessing has to happen upfront! Before you can shift your attention from one object to another, you have to recognize that object regardless of how it is oriented, what the lighting conditions are, what the background is and so on. They aren't saying that this is all serial.
But to me, those higher processes have less to do with vision and more to do with reasoning. I might experience one thought after another concerning some object, but I still see all the objects in front of me.
The company ISI is described in the article as being a leading maker of operating systems for microcontrollers. It's laughable to see some company described as making operating systems as though they were lightbulbs or potato chips!
Mor like, they probably have some common code base that they just tweak a little as needed. It's clearly unlikely that these guys start a whole new operating system project for each customer.
This is probably just a case of ignorant journalism more than anything. Journalists, in the area of technology like in any other area, thrive on sensationalism; blowing things out of proportion.
Slashdot Mirror
Call me nitpicky, but accuracy is important.
:)
- UNIX (in any form that remotely resembles it as we know it now) does not date back to the 60's, but rather early 70's. The very earliest assembly language work started around 1969, when Ken had yet to develop basics like an assembler and editor that would run on the target host, not to mention a higher level language. C wasn't developed until around 1973 or 1974. You wouldn't want to be running most of the operating systems that actually date back to the 60's.
- The GPL does not require you to release modifications. Only if you do release, you must not do so in binary only form. So it's not accurate to say that ``you have to share'', but that ``you can't release the modified software in executable form only''.
- Linux is not just for PC's.
- OpenBSD is not ``security through obscurity''. Matt says that he doesn't want to incite a religious flamewar and then turns around to say that. What about the fact that a bunch of hackers did a line by line security audit that supposedly took a number of years? To use a derogatory term like ``security through obscurity'' is an insult to these people. Sure, there may be an element of obscurity because OpenBSD isn't that popular, but that's no excuse for FUD. Matt blew a perfectly good opportunity to use OpenBSD as an example of how open source code allows people to increase their confidence in systems security.
It's a fair challenge. Obviously they had to be confident that the competitor lacks key features. Database optimization is not all about having a higher -O flag on your compiler.
;)
I wouldn't say that they weren't risking anything. They gave Microsoft three months to catch up, during which time they could have hacked out materialized views---or found someone who could do it for a million bucks, such as some moonlighting Oracle employee.
Moreover, the query doesn't seem to be contrived at all. It's a simple, run of the mill query, applied to a huge database. The Oracle feature which makes the query run fast seems to be an actual real-world advantage, not just some benchmark fodder.
So why can't M$ get it going on the same platform? Oops, I forgot. They have yet to learn to overcome their fear of bytesex. Every version of Windows requires a little endian processor, that's how incompetent they are. Even CE, which runs on RISC platforms like MIPS and Strongarm (which are bi).
:)
Man, Thompson and Ritchie give them the freaking programming language, show them how it's done, give them the freaking programming language and they still don't get it nearly 30 years later.
Fallacy: if you needed compilers to make compilers, we would still be programming by plugging wires into sockets.
The first compiler for the language B had to be written in PDP-7 assembly language, and then re-written in B. As the language was improved,
the improvements were used in its source code.
It took a mere four or five years for Thompson and Ritchie to go from nothing to C+UNIX.
Of course, having existing tools means that you don't have to go through the pain of bootstrapping yourself from nothing! But there is a fine semantic divide between ``difficult'' and ``impossible''.
Also, I did mention that early Linux was compiled with a Borland compiler, so your point about free software needing commercial tools at the outset is somewhat redundant.
That is an interesting point. The next logical step would be a free compiler and libraries to support these apps. Free Pascal seems like step in that direction.
I only *hope*, rather than demand, that people choose not to give up freedom for whatever advantage they hope to gain.
;)
By the way, why is it that your customers depend on you and on Inprise to provide the freedom to choose between NT and Linux? If you didn't provide the choice, could they go to someone else? Some freedom they have there.
Nor a bad thing. It's just another piece of proprietary software that I'm not interested in running on my freedom platform. I hope you won't be seduced either.
Linux hasn't needed Borland since the day it became powerful enough to run GCC and serve as its own development platform.
Some of you are euphoric every time some commercial vendor offers a piece of ``support'' for Linux, because it means that the popularity of your favorite operating system is increasing. So you rejoice at the popularity increase even if you don't plan to use the newly ported product.
Some, like me, would use a freedom platform even if it wasn't popular, and would use freedom software even if it wasn't as good as a proprietary alternative in terms of convenience or performance or other measures. How about you?
I picked Dr. Evil, but now I want a recount.
If the kid loses his card, he ceases to exist. Other kids will walk by him or her, acting as if he or she were not there. The glances of others will seem to shift and focus on objects beyond the individual, never making any contact, as though the individual were invisible.
Actually, the correct techie pluralization of box is ``boxen'' not ``boxes''. So you can rest assured that these people are utterly clueless, and don't have to worry about what this world is coming to.
It makes sense, because it places all of the control on the server side, giving the schools central control over everything.
This is nothing new; universities have relied on labs of XWindow terminals for years and years, which are basically NC's. Again, the advantage there is centralization of resources and security---but most of all, control over the students' use of the equipment.
Interix (previously OpenNT) is a way for developers to ignore proprietary Windows interfaces and continue developing UNIX and POSIX software. They are not fully in the Windows trap because they can easily get out.
Microsoft wants all development to take place using its proprietary interfaces. It's obvious that they bought Interix because they want control. They probably want to exert pressure on Interix users to migrate to real Windoze.
I also predict that Microsoft will maim or kill the project. Whatever the outcome, they have no real incentive to provide a *quality* UNIX layer on NT. They want to be able to tell the customer---look, if you wanna write a real Windoze application that performs and scales, be sensible and use the real thing! Install Visual C++ and start calling Win32!
Now, a historic observation, for what it may be worth: all UNIX emulation layers in the past have bit the dust. Only real kernels have survived. The appearance of an emulation layer has also historically sounded the death knell of the host platform---recall VMS, Apollo Domain/OS, various mainframe platforms...
Cable modems are broadband devices. They use two channels: one for sending and one for receiving. It's possible for the cable company to allocate many pairs of channels on the same cable: in other words, do frequency division multiplexing.
So you are not necessarily on the same LAN with everyone else who is on the same wire as you, and the cable does not necessarily have to be split into segments.
The question is, what does it take for a given cable company to start allocating more channels? I suspect that they just cram as many users onto the same pair of channels as they can, and won't allocate any more until enough people complain.
What's so heart attack inducing about being able to boot Linux from another OS and sharing a filesystem partition between the two? It's been done for years, starting with DOS. You can use LOADLIN to boot Linux from DOS and thanks to the UMSDOS file system, you can have a root partition (with long file names and other comforts) based on a DOS filesystem.
This isn't Linux running ``under'' Windows as an application. It's merely Linux sharing a filesystem with Windows. You still have to reboot to the Linux kernel. Thus I suspect that you are going to, for instance, find it rather inconvenient to interoperate gnupg with your Windows e-mail program.
Any C programmer worth his salt can figure out how to write a module by looking at other modules and the Apache source code.
;)
What kind of hand holding is next? Apache Module Wizard integrated into bash?
Let's face it; most computer books are written purely for profit. Particularly ones about dreary, passionless, narrowly-defined topics like writing extensions to a particular application.
From an instruction set architectural point of view, the eZ80 sounds roughly about as powerful as a MC68000, which was introduced in 1979 and was the first member of its family. Zilog has been playing catch up ever since. First the Z8000, then the Z80000. The pinout of the eZ80 vaguely resembles an 68008. Eight data lines, Twenty four address lines (Okay, so the 68K doesn't have A0, but rather two decoded strobes: UDS and LDS).
;)
As for the instruction set; the Z8000 and Z80000 are rather obscure architectures. According to the eZ80 PDF spec, Z80 programming is supported in some kind of virtual machine mode, probably similar to V86 on 80x86 processors. From what I gather is that you run Z80 code in a 64 kilobyte ``sandbox''. Blech! Whatever abundance of Z80 programming talent may be out there, if I'm to believe you, is only directly applicable to this lobotomized mode. I'm guessing, but the full mode likely has an instruction set that is compatible with the 32 bit Z80000, so you want to be coding in that language.
(You know, a lot of people know 8086 programming! But what does that have to do with 32 bit 80386? Would you build on a 80386 on the justification that you can easily find DOS programmers who can hack 8086 code? Oops.)
It's likely that more people know 68K programming than Z80*000* programming. 68K programming hasn't changed much in twenty years, in the sense that if all you know is the original Motorola instruction set (which is pretty darn nice as far as these things go), you can still make fairly good use of any of the family members, unconstrained by address space or register size issues. That is not the case with these awful 4004 descendants, which, despite maintaining measures of backward compatibility, have undergone radical instruction set transformations.
Anyway, you'd probably want to program a 32 bit processor in a higher level language---so ultimately who cares how nice the instruction set is from the programmer's perspective? You can pick up a new machine language on week's notice if you need to; you just need a solid architecture reference manual.
As for the TCP/IP stack---big deal. All you need is a C compiler and some time to port an existing stack. I suspect that these things are a lot easier to come by for a 68K system, than for a Z80* system. (Here is a question: for one thing, is GCC currently targetted for Z80K?)
But I'm all for diversity: let me know when they have Linux or *BSD running on some Z80* box.
But this is 1999, not 1979.
The eZ80 might offer an upgrade path for current Z80 users, but I don't see how it fits into new product design. (But couldn't a Z80 emulator also take care of some of these users?)
Why would anyone use this over, say, some Motorola 68K family processor or some RISC thing?
Doh!
Looked at in the best light, the license is probably intended cover any Corel proprietary content that may be in the distribution. Obviously, the beta test license cannot conceivably apply to any material that is under the GPL, so you can ignore the license with respect to those components that fall under the GPL (or other licenses incompatible with Corel's).
The only gripe I have is that their license doesn't make it clear what is and what is not covered. Newbies might think that it covers every included item.
So this could be just a case of innocent misrepresentation. My guess is that someone in the company who is vaguely clueless about free software just applied some ``standard'' beta test licensing boiler-plate.
Encryption is a technological protection, yes. But what if you are told that its use is against policy? Remember, you are dealing with assholes who are hell-bent on monitoring everything, who
can spin your use of encryption into a policy violation.
Encrypting your e-mail will prevent your boss (or sysadmin or whoever else) from reading it. But it won't prevent them from detecting that you are encrypting your e-mail.
E-mail encryption is sensible and it should be used for privacy regardless of the nature of your workplace; it is not, however, protection against workplace oppression. The protection against that is to either somehow change the workplace or just leave.
Let us examine why.
;) Those students who are capable of contributing to a sophisticated open source project, an are motivated to do so, will do so regardless of what hell breaks loose at their school.
Firstly, the greatest falsehood in the essay is that it equates UNIX with Linux. Because Linux is a UNIX-like system, anything that affects the position of UNIX in the academic environment is also a threat to Linux. This is false; the real tension here is between open source free software and closed-source proprietary software. Both Windows NT and commercial UNIX fall into one camp when we view things this way. In the face of open source competition in the academic arena, not only Microsoft should be cutting deals, but so should vendors of proprietary UNIX.
Secondly, it is hard to believe that computer science and engineering academics could be persuaded to dump their True opreating systems (whatever those are) in favor of some garbage from Redmond. That is just not going to happen.
Another insinuated falsehood is that Linux has always been accepted in academic environments, and it was accepted purely because it is UNIX-like, and that it is very widely accepted by everyone in all computer science departments everywhere. Linux has flourished in the academic environments *in spite* of commercial UNIX variants. It was perhaps most used among undergraduates, at least initially. It was a long time before Linux made its way into departments, by sneaky routes not unlike those that it has taken in the corporate arena. Many old timer faculty members would scoff at Linux, being BSD freaks or commercial UNIX die-hards. It was (and *is*) hard enough to convince the academics that Linux is any good! Good luck trying to push NT on these people.
It's not like all of computer science went crazy over Linux overnight. Undergraduates flocked to Linux because it gave them a good development platform that was compatible with the systems at school.
This brings me to my final point. Yes, to some extent, Linux did become popular in the university environment among computer science and engineering undergraduates because it provided students with a familiar enviroment. Students could perform computing assignments and then easily back port them to the UNIX machines at school. So it would appear that if the school gradually converts to a non-UNIX operating system, this advantage of Linux will disappear. That much I can buy; what I have a problem with is the logic of the next inference: namely that Linux is somehow endangered by this! Truth is, the students who depend on Linux to provide a familiar homework environment are not particularly significant to the Linux movement. At least, not any more! Linux has a much broader base of users now. Secondly, such users do not contribute to Linux; they are usually very junior programmers. Many of them dump Linux when it is no longer needed for doing homework, in order to make room for Windows games on their hard drives.
In short, I do not buy the view that Linux requires broad, grass-roots support in academia everywhere in order to survive. For that matter, I don't think that it *ever* did require that support, nor did it have that support, and that it has flourished in spite of *opposition* in academic circles as well as corporate environments---the only difference being that there is less UNIX ignorance in academia, which is a two-edged sword (less UNIX ignorance == more UNIX arrogance). I also don't think that the operating systems choosen by computer science or engineering academics have all that much impact on the real world. Otherwise you would see a heck of a lot more UNIX everywhere and far less Windows. The academics, along with their UNIX boxes, could all disappear overnight and it wouldn't make a difference to the future of Linux, nor to the future of anything.
What about office workers who are not ``technologically savvy''? Not everyone knows enough to look for and disable such a thing.
Ignoring that, there could be nevertheless hidden difficulties behind trying to stop something like this. And not all the difficulties are necessarily technological.
If the employer is running software like this one everyone's workstation as a matter of policy, then by disabling it, you are violating company policy. If you get caught trying to disable the software, you could be disciplined or fired. It would be trivial to design monitoring softwarethat cannot be simply turned off without detection. For example, the software could periodically respond to special pings from a central server. Hacking up software to fake the responses could be a major challenge depending on how the program is constructed. If there is some serious crypto authentication, it would have to be reverse engineered and faithfully reproduced in the impostor program. Most people would have to wait for some hacker group to release such an ``anti-big-brother'' impostor.
Another problem is, it would seem suspicious if nothing is being recorded by the monitoring program. You would have to arrange for your impostor program to provide some sensible looking activity record while you conduct personal business. Otherwise you would have to explain the idle periods---and what if the monitoring is being used to detect idle workers as well as ones who are using the equipment for personal use?
A third problem is that even though you stop keyboard monitoring, your employer can still snoop the network. Presumably, any interactions you have with the Internet go through the company's routers. The boss doesn't necessarily need a tedious record of your keystrokes; just some software that can monitor TCP streams and other data. By tapping TCP streams, it should be possible to recover telnet sessions, FTP transfers, ICQ or IRC chats, Usenet reads and posts, etc. This is kind of spying is probably a lot more useful than having some keystroke record. (Of course, one could use an encrypting proxy system, but that alone could draw suspicion.)
I don't think that there is any real technological protection against this. Any such measures treat the symptom rather than the disease anyway! You have to treat the disease. If you happen to fall into such a predicament, organize with other users who are in the same boat, and let the corporation know that you won't take the spying. In other words, the classic organized labor solution to the problem of worker oppression.
Failing that, terrorist tactics might work. The spying has to be implemented by another employee. Simply threaten to, in the parking lot, break the legs of anyone who supports the company's oppressive measures. Distribute an anonymous flyer which threatens to blow up the premises if the spying isn't put to an end by a certain date. Phone in bomb threats. Etc.
As the subject says. The STL is a component of the C++ library standard. The standard specifies what is in the headers; the syntax and semantics of the objects (as well as intended asymptotic running times to somewhat constrain the implementation).
Several open source implementations of the STL are floating around; the best known one is perhaps the one from SGI. The one used by Microsoft was done by P. J. Plauger.
I suspect that the article is talking about very high level cognitive processes. But it's clear that heck of a lot of parallel preprocessing has to happen upfront! Before you can shift your attention from one object to another, you have to recognize that object regardless of how it is oriented, what the lighting conditions are, what the background is and so on. They aren't saying that this is all serial.
But to me, those higher processes have less to do with vision and more to do with reasoning. I might experience one thought after another concerning some object, but I still see all the objects in front of me.
The company ISI is described in the article as being a leading maker of operating systems for microcontrollers. It's laughable to see some company described as making operating systems as though they were lightbulbs or potato chips!
Mor like, they probably have some common code base that they just tweak a little as needed. It's clearly unlikely that these guys start a whole new operating system project for each customer.
This is probably just a case of ignorant journalism more than anything. Journalists, in the area of technology like in any other area, thrive on sensationalism; blowing things out of proportion.