I have very grave concerns about Pinkerton's approach to this problem. Even if we assume that actively attempting to identify potentially violent children is a good thing, it should be left to trained professionals with ethical responsibilities. Peers are neither technically skilled enough to identify danger signs, nor do they have any ethical responsibility to avoid false reporting. Not only will the WAVE system not effectively identify problem students, i can assure you it will generate so much spurious and false data due to erroneous or deliberately misleading reports that it will be worse than useless.
And if such a system becomes widely used, i fear for my child. He is extremely intelligent, but a social loner. He likes computers, and tends to say exactly what he thinks. This doesn't make him any sort of a danger to society, but it does make him a target for WAVE, not to mention a target for bullies. When i was a child, i behaved much as he did. And had access to guns, too (he does not). Did i shoot up my school? Nope. I went on to become a happy, successful and moderately well-adjusted member of society. I'm sure my son will too.
Unless the do-gooders decide to take their advice from the bullies and lock him up. __ (oO) /||\
As the parent of a very intelligent but socially standoffish child, i'm MUCH more worried about my child being falsely profiled as a danger to others.
Basic risk analysis tells us that we'll never know if such a program ever prevents a disaster. But i'd be opposed anyway, just as i'm opposed to imprisoning people because they might someday mug me. When the child acts in a dangerous manner, then by all means take action. But don't take action because the child MIGHT do something dangerous. __ (oO) /||\
XFS contained a fair bit of proprietary code from vendors other than SGI. All of that had to be searched for, removed, and replaced. Not a trivial task. __ (oO) /||\
I'd do the windows as borderless windows with a transparent mask over root, and a little X tweaking to keep the window manager from restacking them. This is how xfishtank and other things work. Moving them around should be no more computationally expensive than grabbing any window and moving it around the screen. If drawing on the root window sucks down the entire CPU, then the design needs some serious examination. I expect to be able to run lots of animations simultaneously without a significant performance hit on a modern desktop PC. If that's a problem, then it is my design that is flawed, not X.
Yes, i'm aware of WxPython, but haven't tried it yet. It may well do what i want, too. Unfortunately, work and life have interfered with fun coding projects.:( __ (oO) /||\
If multiple coders are all trying to actively maintain a project and can't work out their differences, then fork! Any open source license allows that. Either the duplication of effort will be recognized as wasteful and the code will merge, or one will wither on the vine, or we'll wind up with two different useful projects.
I'm actually working on a project to write a replacement for xfishtank, as well as xroach and a couple of other classics, and some ideas of my own (it all started when i went in to try to fix something in xfishtank, and realized i was dealing with code that dates back to X10!). My goal is to develop a generic "sprite" animation mechanism for the X root window, which allows sprites to interact with each other and be aware of other windows on the desktop, and separates the animation images and rules from the display mechanism.
Right now, it's still going through a lot of basic setup and experimenting, but i hope to have source up as soon as i can get a few evenings to hack at it again! The project is at https://sourceforge.net/project/?group_id=2502, but there isn't really anything there yet.
At this point, it is looking like the code will be written mostly in Python, with a small C library for the actual root-window drawing routines and drawing-related events (Xlib, ugh. But i can't seem to do what i want with PyGTK). To create a new animation type, you just inherit from a generic xsprite, and extend with your own movement rules, interaction rules, and animations.
Here are some of the animations i have planned: * fish, a la fishtank * roaches - they try to hide under windows, and scurry when you move them. * tanks - like Atari "Combat" tanks, they drive around the screen trying to shoot each other * spacewar - like the tanks, only with gravity * flames - burning along the tops of windows
Feel free to jump in and help, once i have at least a minimal working system! __ (oO) /||\
$250k for a site that makes $20k a year in ad revenue? That's actually a pretty reasonable price, 12x earnings. It's even more reasonable if you consider growth potential.
Negotiate down a little, but not too much. If they can't see value in the investment, and you want to sell, find someone else to buy it. That shouldn't be too hard.
As a consumer, i figure i pay $50-75/mo for music, mostly on CD. If digital music distribution reduced the cost for music, i wouldn't spend less - i'd just own more music! My music budget is limited by finances, not taste. If music cost 1/10 what it does now, i'd have ten times as much.
And since any online distribution mechanism would cut out middlemen between the artists and the consumers, it would benefit both the artists (more money) and the consumers (more music). The only parties who would lose out are the layers of middlemen between us and our favorite musicians.
I'm all for making sure artists get paid for their work. But the record industry execs who claim they are trying to protect the artists are liars and hypocrites. They screw over artists in more fiscally and artistically destructive ways than all the consumer "thieves" ever could. __ (oO) /||\
Does listing sites criticizing the company as "nudity", "violence", or "profanity" constitute libel? It seems to me that Mattel has opened itself up to a monstrous class action suit here. They are deliberately misrepresenting the content of these sites to their customers.
I would *love* to see one of these filter critic cases end with a libel judgement against the filter software maker. That would maybe give the rest a reason to think before they act.
And i hope whatever employee had to add those things to the database got their orders in writing. And has polished up their resume. __ (oO) /||\
First, choose your enemies wisely. Fighting some poor teenager from the frozen wastelands is easy. Fighting gigantic megacorps is hard. The DVD thought police are making dangerous enemies, enemies on their own turf (see, hackers (in the non-perjorative sense) are not going to fight the battle on their turf. Other corporations will, tho).
Second, what 13-headed hydra of a committee DESIGNED their encryption specs? This is the second glaring hole found. ---
Try this Google search. Read Bob Black's classic rant, "The Abolition of Work". Don't just ignore it where it breaks down... be sure to absorb the good points he does make. If this essay doesn't change your thinking, i don't know what will.
-dave, currently working 60-hour weeks so he can retire early. ---
"Real programmers"? Bah. Don't even get me started on THOSE idiots. Anyone who does their work the hard way BECAUSE it's the hard way is a fool or an amateur (there's nothing wrong with amateurs doing things the hard way... that's for fun!) "Real programmers" brought us those endless x86 assembly language hacks that made already-fragile DOS boxes virtually unusable. They're the guys whose code can't be read because they don't comment anything (much less write design docs...)
Scratch beneath the arrogant surface of a "real programmer" and you'll find someone committing virtually every sin listed in _The Pragmatic Programmer_. ---
And here i had a 3/4-finished Slashdot review of this book going...
Anyway, here's my take on it: if you don't think you will learn anything from this book, or don't think you have time to read it, you are NOT a Pragmatic Programmer. You're probably "coding by coincidence", or perhaps about to be a "boiled frog". Pragmatic programmers know there is always something new to learn, and go looking for it.
This is an eminently *practical* book. It's not some dry treatise on software engineering theory - certainly, it doesn't suffer from the OneTrueWayism of so many academic approaches to writing better software.
Their agnosticism on many divisive issues (such as the best editor) comes from the pragmatic approach. It is pragmatic to learn a high-powered programmer's text editor like vi, Emacs, etc (Notepad is NOT sufficient). It is NOT pragmatic to debate which one is "better". It's a matter of taste. What's more important is mastering the editor you do know. Similarly, they recommend mastering a powerful scripting language, but don't care if it's Perl or Python or whatever. Although they didn't address methodologies much, i'm sure they would suggest learning one solid methodology (patterns, UML, whatever) and mastering it.
The chapter on "Ruthless testing" is especially valuable for most programmers, who generally vary from weak to pathetic when it comes to testing. Rather than just saying "testing is good", they make concrete suggestions. For example, a bug should only be caught by human manual tests *once*... not because the bug should be permanently fixed (this isn't true in practice, no matter how confident programmers are), but because after it is caught once by hand, it should be caught the next time by your automated test suite. You DO have automated tests for your software, don't you? No? Why not? Do you believe your code is bug-free? Are you afraid of what you might find out? I know i am sometimes. Or maybe you're too busy coding new stuff to make sure the old stuff works.
I'll probably go on with more later, but i want to post this now.
Oh, and it *is* a good bathroom book, with chapters and sections of just the right length. Its main weakness as a bathroom book is that you won't want to put it down.:} ---
A finer point of labor law - there is a tradeoff here. Because airlines are a critical industry, airline employee unions are not allowed to go on strike without permission of federal labor mediators. But by the same token, if they DO go on strike (legally), then the employer cannot fire them.
In this case, the employees did not have permission to strike, or to stage quasi-strikes like a sick-out. So, if it turns out that the employees DID organize an illegal sick-out, NWA would be allowed to fire them as no-shows. They weren't sick, they were bullying the company, in defiance of the orders of federal mediators. ---
(disclaimer: my spouse is a non-union NWA employee working in the IT department)
NWA obtained a legal court order to search for evidence of an *illegal* action by the flight attendants. If this was searching for paper rather than computer records, would Slashdot even fucking care? Speech may not be less free because it happens on a computer, but it isn't MORE free, either.
Some background on this case, since the media usually fails us... NWA has been in contract negotiations for i think three years now with the flight attendants, who are represented by the Teamsters. This fall, NWA and the Teamsters negotiators agreed on a contract, and the Teamsters took it to the flight attendants. The flight attendants voted it down. They responded with their list of demands, which would make NWA the industry leader in every single area of employee benefits for flight attendants, and refused to budge from that. The federal mediator then cancelled negotiations, on the grounds that the *flight attendants* were not negotiating in good faith.
Now, federal law prohibits airline employees from striking without court permission. Obviously, if the flight attendants were booted from the negotiating table for acting in bad faith, they aren't going to be allowed to strike. This includes actions like sick-outs. So, when they staged a sick-out, it was basically an illegal action. However, union officials have denied that it was officially organized or sanctioned, because they realize it will further undermine their position.
So presumably, NWA went to court to get the order to search personal computers for evidence that union officials were indeed behind the sick-out - a big win for NWA in court, and a deserved one.
I could make a lot of other points here, but i'll close with this one - speech should be no more or less protected on a computer than on any other media. If union officials stage an illegal action and then deny it, the company has a right to get a court order to search for evidence to the contrary, whether those records are on paper or on computer. ---
So that puts VA trading at, what, 100 to 1? Those stock prices were INSANE. VA's just a PC maker, dammit! The best thing to be said about them is that they aren't beholden to Redmond, but that's faint praise. PC manufacturing is a low-margin industry, which means constant engineering efforts to keep the product up-to-date, as well as excellent warehousing and production business practice, which has *nothing* to do with Linux. Even Dell and Compaq are insanely overpriced... VA is just surreal.
The same goes for Red Hat. They made what, ten million last year? How in the name of Gawd can you justify a valuation in the tens of billions? I know RESTURANTS that do more business than Red Hat!
I wouldn't buy a single share of a "Linux" stock at this point. By any reasonable investing standard, it's a bad idea. Established, profitable companies with long-term predictable growth should trade at something like 20:1... maybe 30:1 if you wanna be wacky. Microsoft trades at roughly 65:1 (not counting questionable accounting practices), and i think their doom is written in their stock price.
If Internet/Linux stocks are "suffering", it's because their valuations mean not just unreasonable, but impossible expectations of long-term performance. ---
In theory, a human can write better assembly than a compiler - in a vacuum. But code doesn't exist in a vacuum, and it becomes less of a vacuum every day. Consider these few issues:
* Cache misses: page faults that cause L1/L2 cache misses (going straight to memory, or worse, to disk) cost thousands, maybe millions of instruction cycles. Do you write all your assembly language to neatly break your data structures across paging lines? No? Didn't think so. btw, this level of optimization can be performed in C in many cases, by good C programmers.
* Pipelining: Do you hand-code your assembly language to give the best hints to the branch decision-making hardware so it can optimize pipelining? Really? You're better than me. Or maybe your code is so much better than compiler-generated crap that the branch lookahead hardware support is useless.
* APIs: I suppose you don't mind reverse-engineering every library call you might ever need, so you can avoid those wasteful, inefficient C headers.
* Et Cetera: The days where humans can outthink compilers in the general case died with the PowerPC and Sparc I. Those of you who have written 1,000,000+ line assembly language programs are free to tell me i'm full of shit. Those of you who have worked on million-plus line code in high-level languages are free to give me an AMEN!!
Vir[ii|uses] are a problem in the Windows world due to a lack of system security, plain and simple. While it is theoretically possible to write a Unix/Linux virus (and has been done), how will it *spread*?
For a classic virus to work, it must attach itself to an executable, and spreads when that executable is run (modern email "virus" programs are often technically worms, not vir[ii|uses]). In Windows, this is easy, because the system directories (c:\Windows) are writable by the regular users.
In Unix/Linux, the system directories where most binaries are (/usr/bin,/usr/lib, etc) are not writable by non-root users. If you don't run as root, a virus can't infect the binaries, because it can't write to them. Period.
If one were to write a Unix/Linux virus, the obvious target program would be/bin/sh (or/bin/bash, etc). Infect this, and you can easily infect everything which is executed by/bin/sh, which is most programs. But how can an ordinary user attach the virus to/bin/sh? On the various Linux and commercial Unix boxen here at work, it is always owned by root/root or bin/bin, and mode 755 or 555 - unwritable by ordinary users.
At best, a virus could affect user-owned binaries, say in ~/bin. But except for convenience scripts, who uses that? Anything widely used and standard goes into a directory protected from accidental or deliberate damage. That's just good practice.
If all operating systems followed Unix' wise example, vir[ii|uses] would be merely an interesting theoretical exercise, rather than a serious hazard.
Slashdot Mirror
I have very grave concerns about Pinkerton's approach to this problem. Even if we assume that actively attempting to identify potentially violent children is a good thing, it should be left to trained professionals with ethical responsibilities. Peers are neither technically skilled enough to identify danger signs, nor do they have any ethical responsibility to avoid false reporting. Not only will the WAVE system not effectively identify problem students, i can assure you it will generate so much spurious and false data due to erroneous or deliberately misleading reports that it will be worse than useless.
/||\
And if such a system becomes widely used, i fear for my child. He is extremely intelligent, but a social loner. He likes computers, and tends to say exactly what he thinks. This doesn't make him any sort of a danger to society, but it does make him a target for WAVE, not to mention a target for bullies. When i was a child, i behaved much as he did. And had access to guns, too (he does not). Did i shoot up my school? Nope. I went on to become a happy, successful and moderately well-adjusted member of society. I'm sure my son will too.
Unless the do-gooders decide to take their advice from the bullies and lock him up.
__
(oO)
As the parent of a very intelligent but socially standoffish child, i'm MUCH more worried about my child being falsely profiled as a danger to others.
/||\
Basic risk analysis tells us that we'll never know if such a program ever prevents a disaster. But i'd be opposed anyway, just as i'm opposed to imprisoning people because they might someday mug me. When the child acts in a dangerous manner, then by all means take action. But don't take action because the child MIGHT do something dangerous.
__
(oO)
XFS contained a fair bit of proprietary code from vendors other than SGI. All of that had to be searched for, removed, and replaced. Not a trivial task.
/||\
__
(oO)
I'd do the windows as borderless windows with a transparent mask over root, and a little X tweaking to keep the window manager from restacking them. This is how xfishtank and other things work. Moving them around should be no more computationally expensive than grabbing any window and moving it around the screen. If drawing on the root window sucks down the entire CPU, then the design needs some serious examination. I expect to be able to run lots of animations simultaneously without a significant performance hit on a modern desktop PC. If that's a problem, then it is my design that is flawed, not X.
/||\
__
(oO)
Yes, i'm aware of WxPython, but haven't tried it yet. It may well do what i want, too. Unfortunately, work and life have interfered with fun coding projects. :(
/||\
__
(oO)
If multiple coders are all trying to actively maintain a project and can't work out their differences, then fork! Any open source license allows that. Either the duplication of effort will be recognized as wasteful and the code will merge, or one will wither on the vine, or we'll wind up with two different useful projects.
/||\
That's what Open Source is for.
__
(oO)
I'm actually working on a project to write a replacement for xfishtank, as well as xroach and a couple of other classics, and some ideas of my own (it all started when i went in to try to fix something in xfishtank, and realized i was dealing with code that dates back to X10!). My goal is to develop a generic "sprite" animation mechanism for the X root window, which allows sprites to interact with each other and be aware of other windows on the desktop, and separates the animation images and rules from the display mechanism.
/||\
Right now, it's still going through a lot of basic setup and experimenting, but i hope to have source up as soon as i can get a few evenings to hack at it again! The project is at https://sourceforge.net/project/?group_id=2502, but there isn't really anything there yet.
At this point, it is looking like the code will be written mostly in Python, with a small C library for the actual root-window drawing routines and drawing-related events (Xlib, ugh. But i can't seem to do what i want with PyGTK). To create a new animation type, you just inherit from a generic xsprite, and extend with your own movement rules, interaction rules, and animations.
Here are some of the animations i have planned:
* fish, a la fishtank
* roaches - they try to hide under windows, and scurry when you move them.
* tanks - like Atari "Combat" tanks, they drive around the screen trying to shoot each other
* spacewar - like the tanks, only with gravity
* flames - burning along the tops of windows
Feel free to jump in and help, once i have at least a minimal working system!
__
(oO)
$250k for a site that makes $20k a year in ad revenue? That's actually a pretty reasonable price, 12x earnings. It's even more reasonable if you consider growth potential.
/||\
Negotiate down a little, but not too much. If they can't see value in the investment, and you want to sell, find someone else to buy it. That shouldn't be too hard.
__
(oO)
Oddly enough, i was already planning on taking a vacation to Boston this weekend. I'll have to stop by.
:P
/||\
And no, i can't tell you details about my job. But at least i can pony up a couple of pre-IPO shares so i can use the restroom.
__
(oO)
As a consumer, i figure i pay $50-75/mo for music, mostly on CD. If digital music distribution reduced the cost for music, i wouldn't spend less - i'd just own more music! My music budget is limited by finances, not taste. If music cost 1/10 what it does now, i'd have ten times as much.
/||\
And since any online distribution mechanism would cut out middlemen between the artists and the consumers, it would benefit both the artists (more money) and the consumers (more music). The only parties who would lose out are the layers of middlemen between us and our favorite musicians.
I'm all for making sure artists get paid for their work. But the record industry execs who claim they are trying to protect the artists are liars and hypocrites. They screw over artists in more fiscally and artistically destructive ways than all the consumer "thieves" ever could.
__
(oO)
Does listing sites criticizing the company as "nudity", "violence", or "profanity" constitute libel? It seems to me that Mattel has opened itself up to a monstrous class action suit here. They are deliberately misrepresenting the content of these sites to their customers.
/||\
I would *love* to see one of these filter critic cases end with a libel judgement against the filter software maker. That would maybe give the rest a reason to think before they act.
And i hope whatever employee had to add those things to the database got their orders in writing. And has polished up their resume.
__
(oO)
Is this real, or FUD?
Now that Congress is involved,
draw your conclusions.
---
First, choose your enemies wisely. Fighting some poor teenager from the frozen wastelands is easy. Fighting gigantic megacorps is hard. The DVD thought police are making dangerous enemies, enemies on their own turf (see, hackers (in the non-perjorative sense) are not going to fight the battle on their turf. Other corporations will, tho).
Second, what 13-headed hydra of a committee DESIGNED their encryption specs? This is the second glaring hole found.
---
Try
this Google search. Read Bob Black's classic rant, "The Abolition of Work". Don't just ignore it where it breaks down... be sure to absorb the good points he does make. If this essay doesn't change your thinking, i don't know what will.
-dave, currently working 60-hour weeks so he can retire early.
---
"Real programmers"? Bah. Don't even get me started on THOSE idiots. Anyone who does their work the hard way BECAUSE it's the hard way is a fool or an amateur (there's nothing wrong with amateurs doing things the hard way... that's for fun!) "Real programmers" brought us those endless x86 assembly language hacks that made already-fragile DOS boxes virtually unusable. They're the guys whose code can't be read because they don't comment anything (much less write design docs...)
Scratch beneath the arrogant surface of a "real programmer" and you'll find someone committing virtually every sin listed in _The Pragmatic Programmer_.
---
And here i had a 3/4-finished Slashdot review of this book going...
:}
Anyway, here's my take on it: if you don't think you will learn anything from this book, or don't think you have time to read it, you are NOT a Pragmatic Programmer. You're probably "coding by coincidence", or perhaps about to be a "boiled frog". Pragmatic programmers know there is always something new to learn, and go looking for it.
This is an eminently *practical* book. It's not some dry treatise on software engineering theory - certainly, it doesn't suffer from the OneTrueWayism of so many academic approaches to writing better software.
Their agnosticism on many divisive issues (such as the best editor) comes from the pragmatic approach. It is pragmatic to learn a high-powered programmer's text editor like vi, Emacs, etc (Notepad is NOT sufficient). It is NOT pragmatic to debate which one is "better". It's a matter of taste. What's more important is mastering the editor you do know. Similarly, they recommend mastering a powerful scripting language, but don't care if it's Perl or Python or whatever. Although they didn't address methodologies much, i'm sure they would suggest learning one solid methodology (patterns, UML, whatever) and mastering it.
The chapter on "Ruthless testing" is especially valuable for most programmers, who generally vary from weak to pathetic when it comes to testing. Rather than just saying "testing is good", they make concrete suggestions. For example, a bug should only be caught by human manual tests *once*... not because the bug should be permanently fixed (this isn't true in practice, no matter how confident programmers are), but because after it is caught once by hand, it should be caught the next time by your automated test suite. You DO have automated tests for your software, don't you? No? Why not? Do you believe your code is bug-free? Are you afraid of what you might find out? I know i am sometimes. Or maybe you're too busy coding new stuff to make sure the old stuff works.
I'll probably go on with more later, but i want to post this now.
Oh, and it *is* a good bathroom book, with chapters and sections of just the right length. Its main weakness as a bathroom book is that you won't want to put it down.
---
A finer point of labor law - there is a tradeoff here. Because airlines are a critical industry, airline employee unions are not allowed to go on strike without permission of federal labor mediators. But by the same token, if they DO go on strike (legally), then the employer cannot fire them.
In this case, the employees did not have permission to strike, or to stage quasi-strikes like a sick-out. So, if it turns out that the employees DID organize an illegal sick-out, NWA would be allowed to fire them as no-shows. They weren't sick, they were bullying the company, in defiance of the orders of federal mediators.
---
(disclaimer: my spouse is a non-union NWA employee working in the IT department)
NWA obtained a legal court order to search for evidence of an *illegal* action by the flight attendants. If this was searching for paper rather than computer records, would Slashdot even fucking care? Speech may not be less free because it happens on a computer, but it isn't MORE free, either.
Some background on this case, since the media usually fails us... NWA has been in contract negotiations for i think three years now with the flight attendants, who are represented by the Teamsters. This fall, NWA and the Teamsters negotiators agreed on a contract, and the Teamsters took it to the flight attendants. The flight attendants voted it down. They responded with their list of demands, which would make NWA the industry leader in every single area of employee benefits for flight attendants, and refused to budge from that. The federal mediator then cancelled negotiations, on the grounds that the *flight attendants* were not negotiating in good faith.
Now, federal law prohibits airline employees from striking without court permission. Obviously, if the flight attendants were booted from the negotiating table for acting in bad faith, they aren't going to be allowed to strike. This includes actions like sick-outs. So, when they staged a sick-out, it was basically an illegal action. However, union officials have denied that it was officially organized or sanctioned, because they realize it will further undermine their position.
So presumably, NWA went to court to get the order to search personal computers for evidence that union officials were indeed behind the sick-out - a big win for NWA in court, and a deserved one.
I could make a lot of other points here, but i'll close with this one - speech should be no more or less protected on a computer than on any other media. If union officials stage an illegal action and then deny it, the company has a right to get a court order to search for evidence to the contrary, whether those records are on paper or on computer.
---
Please answer haiku
with haiku! Why, you may ask?
It is more polite.
Yes, i miscounted
syllables. It's too early
for me to count well.
No need to flame me.
I'm not perfect, but at least
admit my mistakes.
What shall i do now?
I'll gaze Medusa-like on
Natalie Portman!
Haiku is so cool.
Even Natalie Portman
jokes can almost work.
What else can i say?
Hemos sux? BSD rules?
Katz is a windbag?
---
So that puts VA trading at, what, 100 to 1? Those stock prices were INSANE. VA's just a PC maker, dammit! The best thing to be said about them is that they aren't beholden to Redmond, but that's faint praise. PC manufacturing is a low-margin industry, which means constant engineering efforts to keep the product up-to-date, as well as excellent warehousing and production business practice, which has *nothing* to do with Linux. Even Dell and Compaq are insanely overpriced... VA is just surreal.
The same goes for Red Hat. They made what, ten million last year? How in the name of Gawd can you justify a valuation in the tens of billions? I know RESTURANTS that do more business than Red Hat!
I wouldn't buy a single share of a "Linux" stock at this point. By any reasonable investing standard, it's a bad idea. Established, profitable companies with long-term predictable growth should trade at something like 20:1... maybe 30:1 if you wanna be wacky. Microsoft trades at roughly 65:1 (not counting questionable accounting practices), and i think their doom is written in their stock price.
If Internet/Linux stocks are "suffering", it's because their valuations mean not just unreasonable, but impossible expectations of long-term performance.
---
Creative control stays
with Anonymous Cowards,
Natalie Portman
---
In theory, a human can write better assembly than a compiler - in a vacuum. But code doesn't exist in a vacuum, and it becomes less of a vacuum every day. Consider these few issues:
* Cache misses: page faults that cause L1/L2 cache misses (going straight to memory, or worse, to disk) cost thousands, maybe millions of instruction cycles. Do you write all your assembly language to neatly break your data structures across paging lines? No? Didn't think so. btw, this level of optimization can be performed in C in many cases, by good C programmers.
* Pipelining: Do you hand-code your assembly language to give the best hints to the branch decision-making hardware so it can optimize pipelining? Really? You're better than me. Or maybe your code is so much better than compiler-generated crap that the branch lookahead hardware support is useless.
* APIs: I suppose you don't mind reverse-engineering every library call you might ever need, so you can avoid those wasteful, inefficient C headers.
* Et Cetera: The days where humans can outthink compilers in the general case died with the PowerPC and Sparc I. Those of you who have written 1,000,000+ line assembly language programs are free to tell me i'm full of shit. Those of you who have worked on million-plus line code in high-level languages are free to give me an AMEN!!
---
In the View menu, the second item is "Sidebar", with a check by it. Select it to turn it off.
---
All candidates say
Stop porn, terrorists, crypto.
Ignorant morons.
Al Gore invented
the Internet. He is such
an 3133t h4x0r.
His "Open Source" web site
runs on NT/IIS
not Linux/Apache
GWB
begs Bill Gates for donations.
Protection money?
Are we citizens?
Or netizens? Elections
just encourage them.
---
120
chars is barely sufficient
Vir[ii|uses] are a problem in the Windows world due to a lack of system security, plain and simple. While it is theoretically possible to write a Unix/Linux virus (and has been done), how will it *spread*?
/usr/lib, etc) are not writable by non-root users. If you don't run as root, a virus can't infect the binaries, because it can't write to them. Period.
/bin/sh (or /bin/bash, etc). Infect this, and you can easily infect everything which is executed by /bin/sh, which is most programs. But how can an ordinary user attach the virus to /bin/sh? On the various Linux and commercial Unix boxen here at work, it is always owned by root/root or bin/bin, and mode 755 or 555 - unwritable by ordinary users.
For a classic virus to work, it must attach itself to an executable, and spreads when that executable is run (modern email "virus" programs are often technically worms, not vir[ii|uses]). In Windows, this is easy, because the system directories (c:\Windows) are writable by the regular users.
In Unix/Linux, the system directories where most binaries are (/usr/bin,
If one were to write a Unix/Linux virus, the obvious target program would be
At best, a virus could affect user-owned binaries, say in ~/bin. But except for convenience scripts, who uses that? Anything widely used and standard goes into a directory protected from accidental or deliberate damage. That's just good practice.
If all operating systems followed Unix' wise example, vir[ii|uses] would be merely an interesting theoretical exercise, rather than a serious hazard.
---
120
chars is barely sufficient