Why do the editors of Slashdot ALWAYS put their unproductive, derogatory, flaming, two cents at the end of _every_ story regarding something "AWFUL" Microsoft has done?
I guess that's fair comment. I have no problem with Tac's rather tongue-in-cheek "Not that there's a problem with Windows security", but your mileage, as the saying goes, may vary.
I have been in the biz for over twenty years, and I've seen that kind of dig in just about every special interest group I've ever attended. Slashdot isn't exactly aiming to be unbiased.
If this really bothers anyone, there's an option in preferences to ignore stories by some editors.
All very well, but I wonder if they wouldn't be better starting with a BSD base if long uptime and file system reliability is an issue. They'll have to introduce something better than ext2fs anyway, so why bother working from a kernel that boots from that filesystem?
Don't get me wrong, I run Linux on my home servers, but I would run it on kit that had the operational requirements that go with those hefty price tags.
Clever bits include running its own SMTP
service to increase chance of success
At first sight, I thought this implied a server component of some kind polling likely looking IP numbers for usable port 25. I was probably being too paranoid, though. I take it that the thing just writes directly to port 25 rather than using the VBA hooks to the mailer?
Perhaps someone who has seen the code could comment.
As for being "platform neutral", it should be. The "web" was never designed to be used for a particular OS or browser (though Microsoft would like to believe otherwise.
What that review doesn't tell me is whether the book addresses security as a software issue. Many system exploits can be traced to specific programming practices, often to kernel level, but more often in userspace code. The above review tells me it's that kind of book I might take a look at, but I'm left wondering if perhaps the book that would give me an insight into how to produce more secure system configurations and help my team to write more secure code has not yet been written.
As a senior web and database developer, I'm probably more likely to check into security mailing lists and watch out for advisories about the core products of my service delivery systems (whether PHP, JSP, Vignette, Apache, IAS, or whatever). Still, any book that raises awareness of security issues and introduces key concepts in an easy to understand manner is to be applauded.
Well I note that my kids commonly carry some gigabytes of memory around with them in the form of minidiscs, CDs and whatnot, so I don't see that having a ROM chip rivalling a CD in size is such a big stretch. It will almost certainly have its uses.
I think we need to go back to the origin of the perception that open source software could pose any kind of threat to Microsoft. This was the Halloween Memo in which Vinod Valloppillil identified the open source community as a potential threat to its server products. And it wasn't so much open source itself, as the commoditizing of network protocols (read: open networking standards) that made open source server software in the first place, that threatened Microsoft's ability to impose a lock-in strategy on its users.
It wouldn't matter much to Microsoft if even 20% of users chose open source software systems--as long as the sites they browsed continued to use Microsoft servers. Microsoft already gets licence money from the PC vendor for most of the new PCs that ship worldwide. But when an IT operation doesn't choose Microsoft's closed systems, it loses the power to command the market in the long term by imposing lock-in at the protocol level.
I tried using Linux KDE as a desktop last year and was disappointed with the speed of the graphical interface. I could watch the dialogs painting and this was on a 900MHz machine.
Interesting. I used KDE under SuSE 5.3 a couple of years back, and performance was acceptable. On a 90MHz Pentium with a 2MB video card and 64MB on the main board. I use Ximian Gnome under Debian 2.2 Potato these days, on a 150MHZ Thinkpad with only 32MB system memory and neomagic video hardware. Sometimes screen updates get sluggish, but then the hardware I'm using in these instances is antiquated and underpowered. It sounds to me like you may have had problems with your KDE configuration.
Notwithstanding the justified celebration of Perl 1.0, Perl was already significant enough to be marked by Dan Faigin and Mark Biggar as "Age 3mo" in this announcement of another fine product:
the occasion was the birth Larry's third child, in May of 1987.
On that reckoning, Perl will be fifteen years old this coming February.
Schools are a tough nut to crack for OSS, because students have no moral qualms about piracy and a lot of professors demand closed file formats for assignments to be electronically filed.
I think that may change in time as teachers are faced with paying licence charges to keep current or moving to open source. On the other hand, MS probably values the education sector enough to continue to cut a lot of slack.
My teenaged son is supposed to file his essays in a format readable by MS Word, but this means that RTF is acceptable.
From my experience of using the Microsoft environment, I think the main attraction was the ease of use. When I wanted to do Network Neighborhood-style network browsing on my office RedHat desktop, for instance, I had to borrow a smbconfig from my network admin _plus_ google for the excellent LinNeighborhood and install it. No problem for me, but the fact is that neither my network admin nor my colleagues, who use and program Linux, and Solaris boxen for a living, had ever heard of LinNeighborhood.
Windows network browsing is comparatively easy to set up--not something for a complete novice, but the sort of intermediate task that a reasonably competent office worker can pick up without any problems. It's just not as well supported in Linux, even though the underlying software, Samba, is a really great product.
I guess I can overlook the rather parochial tone of the phrase "contrary to the belief..." I'm sure many comments have been quick to point out that the belief in question is held almost exclusively by people who do not know the significance of the letter "I" in ISS.
But it's true that NASA involvement is now crucial, and on that point the decision of Congress is sovereign. If you are a US voter and you disagree with Congress's decisions on NASA funding, you know what to do.
On the bright side, I don't think space is going to go away any time soon, and not only are there still many delightful things to explore on earth, outer space itself is becoming far more accessible in the form of robot probes and orbiting telescopes.
Whilst curtailment of the ISS would be bad news for manned space flight in the short term, I don't think it would necessarily be bad news for science as a whole. There is just so much else upon which it would be at least as sensible to spend the science budget of any country.
You're right, I was wrong to imply that it was small. In fact, I write from a European vantage point and was comparing local markets against global market. In such a context, I would probably have referred to the US market as small. Which would also be wrong. The contrast is between the local homogeneous market that you know well and the larger collection of heterogeneous markets that you don't know or are not yet interested in testing.
Maybe if osX was to go multi-platform, then I'd care...
Darwin, the NeXT-like BSD/mach core of MacOS X, runs on Intel kit. It's foreseeable that this may eventually provide a compatibility engine that will permit Mac software developers to port to the cheaper kit. On the other hand, I can't think what strategy Apple would be able to adopt to compete in the large, competitive hardware market that this would create, except by making its GUI interface a major selling point. That would be feasible if Microsoft continued to bite the hands that feed it (which, on previous showings I suppose, is always possible).
Actually, this doesn't sound like such a crazy idea. A friend was trying to impress me with the one of these Titanium book thingies the other day, but all I could think about was how much nicer it would be if I could run the same lovely Mac software on kit at a price point that *I* chose.
[nostradamus mode off]
I have nothing but admiration for Apple's recent moves--successfully leveraging the large open source developer base has given the company a lot of credibility, completing the revamp that started with the iMac. I would never spend any money on Apple hardware (it's far too expensive in my country), but they've got the makings of a great cross-platform OS.
What is worrying is that now business is trying, through the ever tightening web of copyrights, to take ownership of what seem to be demostrated to be universal human myths.
You cannot copyright an idea, only its tangible expression. So the Arthur legend cannot be copyrighted, but individual works based upon it can be. I can legally write my own version of the story, even copying large passages wholesale and word-for-word from authors whose copyright has lapsed. What I cannot get away with is, say, performing the song "Camelot" without paying royalties to the lyricist, composer and arranger, or pillaging the script of the John Boorman movie Excalibur without paying royalties to the script writer. Even so, in time the copyright on these works will all lapse and they will enter the public domain.
I do agree with you on one point, however. It's fairly common for mass distribution of original works to be the privilege of some large companies that have the power to force the originator of a work to assign rights. This can work against the true spirit of intellectual property legislation, which is (generally) to encourage the production of new original works by ensuring that the originator is rewarded.
Back in the 1970s I had a friend who would get her jollies by using the POKE command (if you don't know, you're too young to ask...) on some defenseless PACMAN clone (written in PET Basic in those far-off days) to make the ghosts do weird things like following the maze walls or reversing the normal chase-flee cycle. It was sometimes quite fun, in a watching-paint-dry kind of way. The thought of hacking a game so as to give the impression that one was playing and winning did occasionally occur to us, but it seemed so lame we didn't bother. We were both programmers, dammit (we both still are) and actually playing the game was for users. Plus ca change.
Some people have pointed out the general reason--it's much cheaper to launch in a small test market.
This goes double for a company whose home market is sophisticated, inward-looking and protected by a strong language barrier.
There is no technical reason why an American company should not launch a Cube/DVD hybrid, and no technical reason why a US GameCube shouldn't play both Japanese and US games. These aren't technological issues at all. Markets aren't always quite so free as to operate in the interests of the consumer, although they're usually just free enough to operate in the interests of those who wish to profit by export.
Re:FreeBSD probably has a more sensible policy her
on
Linux Kernel 2.5.1 is Out
·
· Score: 3, Informative
What follows is a kernel newbie's comment on the development of BSD and Linux kernels.
BSD kernel development and Linux kernel development seem to be examples of two very different paradigms[1]
FreeBSD[2] kernel development, bug tracking and fixing appear to be very formal, resulting in a rather sedate evolution. Linux versions of the same thing, although every bit as centralised as BSD projects (or even more so, because Linus decides what goes into the release), appears to be much less formal--I can find no Linux equivalent of
FreeBSD's bug tracking system.
The FreeBSD project does also appear to have more rigid project management. It's also much more of a single entity, too. Whereas the Linux kernel project is distinct from the distributions that use it, typically a BSD project includes management of everything from kernel development through package management to documentation, promotion and distribution of source media.
[1] Sorry for dumping the p-word on you without warning there, but I think it's merited in this case [G,D&R].
[2] Taking FreeBSD as an example of a BSD project.
Since it's only been one revision, it can't have destabilized that much... It takes as much work to destabilize a kernel as it did to stabilize it, so don't expect crashes and corruption right away.
You may be right with respect to most software, but remember that this is an O/S kernel--it has absolutely unfettered control of the hardware. It can take just one serious barf at kernel level to turn it into an active menace. Looking at Kernel.org, I see the notice:
Don't use the 2.4.15/2.5.0 kernel. It has a filesystem corruption bug
in it. 2.4.15-pre8 or 2.4.16-pre1 should be OK; 2.4.15-pre9 has the
same bug.
Caution is recommended. A kernel can eat your filesystem.
Actually, you can spoof the two sides. We would break the fiber between Alice and Bob. Handle the negotiation like Bob would when talking to Alice, and similarly handle the negotiation with Bob like Alice would.
Quantum cryptography scenarios normally assume that there exists a public channel upon which Alice and Bob can communicate without the information they communicate being corrupted. The quantum channel is only used for sending uncollapsed wave packets from Alice to Bob, which Bob then collapses in a random manner. They then use the public channel to verify that an untampered communication of data occurred. They just rinse and repeat until the shared key is transmitted.
It's one thing to intercept a closed channel and substitute bad data, quite another to jam a public channel (a radio broadcast, for instance, or a voice call). You could always verify identity using a few bits from the good old one time pad:)
As soon as Alice and Bob are able to confer on the public channel, Eve's intervention will be evident, and they'll just try again until they are able to establish an untampered quantum channel and Alice can communicate the shared key to Bob.
The importance of this Linux BIOS project is not that it provides a way of doctoring motherboards so that they will not load Windows (and in any case, such an effort could hardly pose any commercial threat to Microsoft).
Nor is it that the BIOS is free software--there are other open source BIOS projects that can perform a DOS/Windows boot.
It isn't even that LinuxBIOS is suitable for embedded systems--other free BIOS's will support embedded systems and can perform a DOS/Windows boot.
In any case, there's nothing to stop someone writing a DOS/Windows boot loader and booting it from LinuxBIOS.
The point, surely, is that "LinuxBIOS
generally weighs in under 64KB and doesn't waste ROM space with
unnecessary functionality. Because it isn't a legacy design,
LinuxBIOS starts up fast, even without code optimization."
It really just provides a nice slimmed down boot cycle suitable for embedded systems that do not require the PC BIOS baggage.
We're not even talking about manufacturers dropping DOS/Windows compatibility, simply one or two equipment providers considering using LinuxBIOS in situations where compatibility is unnecessary and speed to boot is an important factor.
This introduction explains how the quantum channel is used by Alice and Bob to negotiate a key. Sure, you could eavesdrop, but having read the stream does not enable you to clone it in a way that would spoof Bob.
So far they've figured out how to emit one photon, but they don't know how to read it.
Andrew Shields and others released a paper last year on possible use of normal FET technology in conjunction with a layer of
"nanometer-sized quantum dots" for the detection of a single photon. I'm not sure that the method he demonstrates there could be adapted to commercial scale crypto, but it certainly seems to be a possibility.
I'm no expert, and Shields' comments on problems of attenuation in fiber transmitters may render the unique selling point of quantum crypto (that snooping can be detected) moot, but it still looks very promising for such a young idea.
I don't think it's realistic to attempt to pin the development of memonic programming concepts on one person--the first mnemonic assembler language was probably developed for the EDSAC at Cambridge, England, some time before UNIVAC ran its first program.
Programming ENIAC must have been a challenge, because what you had was basically a set of vacuum tube shift registers and whatnot that had to be wired together for a given purpose using patchboards.
I guess that's fair comment. I have no problem with Tac's rather tongue-in-cheek "Not that there's a problem with Windows security", but your mileage, as the saying goes, may vary. I have been in the biz for over twenty years, and I've seen that kind of dig in just about every special interest group I've ever attended. Slashdot isn't exactly aiming to be unbiased.
If this really bothers anyone, there's an option in preferences to ignore stories by some editors.
Don't get me wrong, I run Linux on my home servers, but I would run it on kit that had the operational requirements that go with those hefty price tags.
At first sight, I thought this implied a server component of some kind polling likely looking IP numbers for usable port 25. I was probably being too paranoid, though. I take it that the thing just writes directly to port 25 rather than using the VBA hooks to the mailer?
Perhaps someone who has seen the code could comment.
It's not just Microsoft's own sites that have locked out non-Microsoft browsers--the UK government's Microsoft-commissioned site for electronic filing of tax returns was in the news earlier this year when non-MSIE users found themselves locked out. Fortunately, the British have shown some sense, and a recent report acknowledged that "Properly configured open source software can be at least as secure as proprietary systems, and open source software is currently subject to fewer Internet attacks."
The government is set to conform to an EU strategy to make more use of open source software.
As a senior web and database developer, I'm probably more likely to check into security mailing lists and watch out for advisories about the core products of my service delivery systems (whether PHP, JSP, Vignette, Apache, IAS, or whatever). Still, any book that raises awareness of security issues and introduces key concepts in an easy to understand manner is to be applauded.
Well I note that my kids commonly carry some gigabytes of memory around with them in the form of minidiscs, CDs and whatnot, so I don't see that having a ROM chip rivalling a CD in size is such a big stretch. It will almost certainly have its uses.
It wouldn't matter much to Microsoft if even 20% of users chose open source software systems--as long as the sites they browsed continued to use Microsoft servers. Microsoft already gets licence money from the PC vendor for most of the new PCs that ship worldwide. But when an IT operation doesn't choose Microsoft's closed systems, it loses the power to command the market in the long term by imposing lock-in at the protocol level.
Interesting. I used KDE under SuSE 5.3 a couple of years back, and performance was acceptable. On a 90MHz Pentium with a 2MB video card and 64MB on the main board. I use Ximian Gnome under Debian 2.2 Potato these days, on a 150MHZ Thinkpad with only 32MB system memory and neomagic video hardware. Sometimes screen updates get sluggish, but then the hardware I'm using in these instances is antiquated and underpowered. It sounds to me like you may have had problems with your KDE configuration.
the occasion was the birth Larry's third child, in May of 1987.
On that reckoning, Perl will be fifteen years old this coming February.
I think that may change in time as teachers are faced with paying licence charges to keep current or moving to open source. On the other hand, MS probably values the education sector enough to continue to cut a lot of slack.
My teenaged son is supposed to file his essays in a format readable by MS Word, but this means that RTF is acceptable.
From my experience of using the Microsoft environment, I think the main attraction was the ease of use. When I wanted to do Network Neighborhood-style network browsing on my office RedHat desktop, for instance, I had to borrow a smbconfig from my network admin _plus_ google for the excellent LinNeighborhood and install it. No problem for me, but the fact is that neither my network admin nor my colleagues, who use and program Linux, and Solaris boxen for a living, had ever heard of LinNeighborhood.
Windows network browsing is comparatively easy to set up--not something for a complete novice, but the sort of intermediate task that a reasonably competent office worker can pick up without any problems. It's just not as well supported in Linux, even though the underlying software, Samba, is a really great product.
The cheat to end all cheats.
GAME OVER
But it's true that NASA involvement is now crucial, and on that point the decision of Congress is sovereign. If you are a US voter and you disagree with Congress's decisions on NASA funding, you know what to do.
On the bright side, I don't think space is going to go away any time soon, and not only are there still many delightful things to explore on earth, outer space itself is becoming far more accessible in the form of robot probes and orbiting telescopes.
Whilst curtailment of the ISS would be bad news for manned space flight in the short term, I don't think it would necessarily be bad news for science as a whole. There is just so much else upon which it would be at least as sensible to spend the science budget of any country.
You're right, I was wrong to imply that it was small. In fact, I write from a European vantage point and was comparing local markets against global market. In such a context, I would probably have referred to the US market as small. Which would also be wrong. The contrast is between the local homogeneous market that you know well and the larger collection of heterogeneous markets that you don't know or are not yet interested in testing.
Darwin, the NeXT-like BSD/mach core of MacOS X, runs on Intel kit. It's foreseeable that this may eventually provide a compatibility engine that will permit Mac software developers to port to the cheaper kit. On the other hand, I can't think what strategy Apple would be able to adopt to compete in the large, competitive hardware market that this would create, except by making its GUI interface a major selling point. That would be feasible if Microsoft continued to bite the hands that feed it (which, on previous showings I suppose, is always possible).
Actually, this doesn't sound like such a crazy idea. A friend was trying to impress me with the one of these Titanium book thingies the other day, but all I could think about was how much nicer it would be if I could run the same lovely Mac software on kit at a price point that *I* chose.
[nostradamus mode off]
I have nothing but admiration for Apple's recent moves--successfully leveraging the large open source developer base has given the company a lot of credibility, completing the revamp that started with the iMac. I would never spend any money on Apple hardware (it's far too expensive in my country), but they've got the makings of a great cross-platform OS.
You cannot copyright an idea, only its tangible expression. So the Arthur legend cannot be copyrighted, but individual works based upon it can be. I can legally write my own version of the story, even copying large passages wholesale and word-for-word from authors whose copyright has lapsed. What I cannot get away with is, say, performing the song "Camelot" without paying royalties to the lyricist, composer and arranger, or pillaging the script of the John Boorman movie Excalibur without paying royalties to the script writer. Even so, in time the copyright on these works will all lapse and they will enter the public domain.
I do agree with you on one point, however. It's fairly common for mass distribution of original works to be the privilege of some large companies that have the power to force the originator of a work to assign rights. This can work against the true spirit of intellectual property legislation, which is (generally) to encourage the production of new original works by ensuring that the originator is rewarded.
Back in the 1970s I had a friend who would get her jollies by using the POKE command (if you don't know, you're too young to ask...) on some defenseless PACMAN clone (written in PET Basic in those far-off days) to make the ghosts do weird things like following the maze walls or reversing the normal chase-flee cycle. It was sometimes quite fun, in a watching-paint-dry kind of way. The thought of hacking a game so as to give the impression that one was playing and winning did occasionally occur to us, but it seemed so lame we didn't bother. We were both programmers, dammit (we both still are) and actually playing the game was for users. Plus ca change.
This goes double for a company whose home market is sophisticated, inward-looking and protected by a strong language barrier.
There is no technical reason why an American company should not launch a Cube/DVD hybrid, and no technical reason why a US GameCube shouldn't play both Japanese and US games. These aren't technological issues at all. Markets aren't always quite so free as to operate in the interests of the consumer, although they're usually just free enough to operate in the interests of those who wish to profit by export.
BSD kernel development and Linux kernel development seem to be examples of two very different paradigms[1]
FreeBSD[2] kernel development, bug tracking and fixing appear to be very formal, resulting in a rather sedate evolution. Linux versions of the same thing, although every bit as centralised as BSD projects (or even more so, because Linus decides what goes into the release), appears to be much less formal--I can find no Linux equivalent of FreeBSD's bug tracking system.
The FreeBSD project does also appear to have more rigid project management. It's also much more of a single entity, too. Whereas the Linux kernel project is distinct from the distributions that use it, typically a BSD project includes management of everything from kernel development through package management to documentation, promotion and distribution of source media.
[1] Sorry for dumping the p-word on you without warning there, but I think it's merited in this case [G,D&R].
[2] Taking FreeBSD as an example of a BSD project.
You may be right with respect to most software, but remember that this is an O/S kernel--it has absolutely unfettered control of the hardware. It can take just one serious barf at kernel level to turn it into an active menace. Looking at Kernel.org, I see the notice:
Don't use the 2.4.15/2.5.0 kernel. It has a filesystem corruption bug in it. 2.4.15-pre8 or 2.4.16-pre1 should be OK; 2.4.15-pre9 has the same bug.
Caution is recommended. A kernel can eat your filesystem.
Quantum cryptography scenarios normally assume that there exists a public channel upon which Alice and Bob can communicate without the information they communicate being corrupted. The quantum channel is only used for sending uncollapsed wave packets from Alice to Bob, which Bob then collapses in a random manner. They then use the public channel to verify that an untampered communication of data occurred. They just rinse and repeat until the shared key is transmitted.
It's one thing to intercept a closed channel and substitute bad data, quite another to jam a public channel (a radio broadcast, for instance, or a voice call). You could always verify identity using a few bits from the good old one time pad :)
As soon as Alice and Bob are able to confer on the public channel, Eve's intervention will be evident, and they'll just try again until they are able to establish an untampered quantum channel and Alice can communicate the shared key to Bob.
Nor is it that the BIOS is free software--there are other open source BIOS projects that can perform a DOS/Windows boot.
It isn't even that LinuxBIOS is suitable for embedded systems--other free BIOS's will support embedded systems and can perform a DOS/Windows boot.
In any case, there's nothing to stop someone writing a DOS/Windows boot loader and booting it from LinuxBIOS.
The point, surely, is that "LinuxBIOS generally weighs in under 64KB and doesn't waste ROM space with unnecessary functionality. Because it isn't a legacy design, LinuxBIOS starts up fast, even without code optimization."
It really just provides a nice slimmed down boot cycle suitable for embedded systems that do not require the PC BIOS baggage. We're not even talking about manufacturers dropping DOS/Windows compatibility, simply one or two equipment providers considering using LinuxBIOS in situations where compatibility is unnecessary and speed to boot is an important factor.
This introduction explains how the quantum channel is used by Alice and Bob to negotiate a key. Sure, you could eavesdrop, but having read the stream does not enable you to clone it in a way that would spoof Bob.
Andrew Shields and others released a paper last year on possible use of normal FET technology in conjunction with a layer of "nanometer-sized quantum dots" for the detection of a single photon. I'm not sure that the method he demonstrates there could be adapted to commercial scale crypto, but it certainly seems to be a possibility.
I'm no expert, and Shields' comments on problems of attenuation in fiber transmitters may render the unique selling point of quantum crypto (that snooping can be detected) moot, but it still looks very promising for such a young idea.
I don't think it's realistic to attempt to pin the development of memonic programming concepts on one person--the first mnemonic assembler language was probably developed for the EDSAC at Cambridge, England, some time before UNIVAC ran its first program.
Programming ENIAC must have been a challenge, because what you had was basically a set of vacuum tube shift registers and whatnot that had to be wired together for a given purpose using patchboards.