I found the second link (re: kernel developer getting uppity with SCO) to be much more interesting. He claims to be the author (or significant modifier) of code which SCO purports to be in violation. His remark in short is "The violation is yours, 'cause I wrote the code". In a challenge to SCO, he's threatening to sue SCO unless they remove the paticular code sections from their list of copyright violations.
Actually, it's GPL-based. Derivitive works must be distributed under the GPL. By distributing a derivitive work (that includes what is allegedly their code) and claiming that part of it is not GPL, they are violating the GPL, which invalidates any right SCO had to distribute the code he and every other Linux developer wrote.
I'm also under the impression that the `traditional' linux scheduler (before the rewrite by Ingo Molnar in 2.5) is one of the oldest parts of linux, predating any involvement by IBM or any other large company with access to SCO source. [but this is just my impression from reading the LKML, not based on any research!]
If the new 2.5 scheduler is the point of contention, that might explain SCO's lack of urgency to cease distribution of their Linux. If the Linux stuff they distributed was 2.4, they weren't leaking their trade secret stuff.
The exorcism scene bothered me the most. It seems that due to time requirements they couldn't have Gandalf go to Isengard to confront Saruman, so they combined the Theodin and Saruman scenes into one. But in doing so, they really hollywood-ized magic in Middle Earth. In the books, mind control magic was subtle yet powerful trickery. Less like The Exorcist and more like manufacturing support for a war in Iraq.
I care because I have not fallen for the "golden ears" fallacy. To me, 192kbps ABR lame-encoded sounds exactly like the original. I don't have super expensive speakers attached to the computer, nor do I have a fancy sound card (Creative Live 5.1.) Storing music losslessly is a waste of space to me.
The only problem is, if MP3 or AAC or whatever lossy format fall out of fashion (due to patent or whatever), you could end up with a bunch of files you can't play on the latest gadgets and software. Then you need to re-encode them in whatever the new format, which will add additional lossiness due to the transcoding (unless you re-rip everything, which is a major pain).
If you use a lossless algorithm, you can re-encode to whatever you like. For example, it wouldn't be terribly difficult to take a losslessly-encoded file, decompress it, and run it through a fast MP3 encoder as part of the process of copying the file to your portable. Then if ACC or OGG or whatever displace MP3, you can just change the script when you upgrade your portable.
I agree about the "golden ear" fallacy. Some people avoid lossy because they want "perfect" sound. But there is no "perfect", really... the original recording required sound travelling through air, which is lossy. The recording equipment was also lossy, as is your playback equipment. Your ears and mind are also lossy. Very lossy, in fact... Your ears being lossy is why these lossy audio codecs work as well as they do (they "lose" the parts that your ears/mind would lose anyway).
YOu'd have the same problem with Linux. First you have brilliant distros like Lindows that run as root by default. Then you'll have tons of people who log in as root all the time for dumb reasons like "I get sick of chainging users to do something" or "It's my system, I should be in complete control.
Except with most/all mail clients for Linux (and probably most mail clients for Windows too; pretty much all of them except MS's) you can't invoke executable content without first saving it, and then going back and explicitly executing it from your shell prompt / Run menu.
Collections should be first-class entities
on
Preview of Java 1.5
·
· Score: 3, Insightful
Also look at what you can do with variable arity functions. Say you have a constructor for a collection class and you want to be able to initialize a variable number of default values.
You can already declare arrays in-line. So if they were to define an appropriate constructor, you could do List l = new ArrayList(new Object[] { "foo", "bar", "baz" }).
That is verbose of course. What they really should do is add collection manipulation stuff to the language, so you could go List l = ( "foo", "bar", "baz" ) and be done with it.
I believe that that scripting languages get most of their advantages (more functionality with less code, easy to develop in, etc) because they have collections as first-class entities. It's not as if it would be polluting the language... How often do you write code that doesn't use some kind of aggregate data type? For the language to not recognize that is just silly.
Now if we coul donly free java from the cluches of Mordor(SUN)....
Um, no... Microsoft is Mordor. (Duh!)
Sun is Isengard. You know... pretends to be on the side of good, really just wants to betray both sides and set himself up as the new Dark Lord, but in doing so is unwittingly serving Micr^WSauron.
Why not just put the bs.close(); right after the// Do some stuff and lose the finally block altogether?
Because if an exception is thrown, you still want the file to be closed.
If you don't find finally useful, you are probably not a defensive coder. Cleanup code (such as calling close()) belongs in a finally block. That way it is sure to be executed, no matter what happens in the try block (barring horrible death of the JVM, power failure, etc). Even if the try block throws an OutOfMemoryError or some other thing you would have no reason to catch, the cleanup code will be called.
If you don't explicitly call close(), the file will still be closed when the garbage collector invokes the destructor, but who knows when that will happen. On some systems with broken filesystem concepts (eg. win32) having an open file will prevent other cleanup operations like delete from working.
Finally is also useful if you simply want to return (or throw) within the try block. Instead of having to duplicate your cleanup code at every point where you return, or do contortions with a "retval" variable and force program flow to pass to the cleanup code before returning, just place the cleanup code in the finally block and place your return statements wherever they naturally belong in the try block. The finally block is guaranteed be invoked as execution leaves the try block, no matter how you leave the try block.
Also, it's statically typed. It's so fucking annoying to have to typecast everything - I know I have a damn String - quit holding my fucking hand!
You may know you have a String, but the junior programmer who just came on may not, and will be trying to read your code. All the typecasting in Java is annoying, but it does improve readability. He'll also be writing his own code, and if he thinks he has a String when he doesn't, the compiler will tell him.
That is why Java is so successful. It sacrifices convenience for safety, to protect a probject from inexperienced developers. And while you may not be an inexperienced developer, if you spend any amount of time on large projects you will have to work with them. Better that the language does the hand-holding for the juniors, so the senior developers don't have to (as much).
Sure there is some casting that is clearly redundant, eg. "String name = (String)i.next();". Generics should eliminate those stupid parts.
What is really the difference between using properties like that and just using public variables?
The whole point of getter/setter methods versus simply making the variable public is to allow other things to happen when the get/set occurs. For example, the return value of the getter method may be generated at call time. Or, maybe you want to fire property change events when the setter method is called (observer pattern, very useful in a model-view-controller structured GUI program (among other things)).
Even if you aren't doing anything fancy, you should use getter/setter methods right from the start, in case you change your mind later. And it's easier to remember to just always use getFoo/setFoo, rather than trying to remember where you need getFoo/setFoo and where you need foo = . With editor macros its not really any extra work to use get/set, so there's no reason not to use the more flexible mechanism.
You should also declare them final: "public static final SenseEnumeration...". This prevents accidental re-assignment of the field (reports an error at compile-time), and allows the compiler to do some optimizations because it knows the field will never change.
IE still does not fully support PNG graphics, specifically, it does not support alpha blending, one of the major features of PNG.
True, but JPEG and GIF don't support alpha blending on any browser, so it's not as if the lack of alpha support in IE is holding people to those older formats.
Still, alpha transparency is a Good Thing, that many web artists would use to good effect if Microsoft would let them. There is a petition to get MS to fix IE.
Java exception verbosity is a serious problem. Many times I've heard of "java.lang" errors. The correct solution to this problem is to use C-style exception handling:
Give us a break; if he felt that strongly about the war, he could've said, "Thanks, but I'll wait till you guys leave Iraq before I'll accept your money."
I think it's good that he took the money. It's $2M that won't be spent on death and destruction.
According to this FAQ from Microsoft, java will receive no more support at all in the future. Without using a Windows-only solution such as ActiveX, what other options are there?
For those who are just tuning in...
Back in the mid 90s, when Java hype was at its thickest, some hypesters openly proclaimed that Java would kill Microsoft. And the Dark Lord himself quailed in fear: "This scares the hell out of me."
So, MS responded in a way that only MS could. They used their OS monopoly to neutralize the competitor. MS killed Netscape, leaving IE as the only viable middleware platform. Then they created (and shipped with IE/Windows) their own polluted JRE to fuck with the Java specification.
This gave MS time to develop.NET, which will (among other things) provide an applet capability to replace ActiveX (which has an ass-sucking security model compared to Java).
So have patience, SkyLeach. In a few years everyone will be running some version of Internet Explorer with a.NET CLR. You will be able to write your program in any.NET enabled language and it will run on all those systems.
So you'll have your applet technology. You can have any technology you want, as long as you're willing to wait years for MS to wrest control and approve it.
You do realize that it takes about 4 mouse clicks to make WinXP to look exactly like Win2k, right?
Except it doesn't look exactly like Win2k. The individual UI elements go back to looking like Win2K, but button placement menu structure and such are all still XP.
And you still get those annoying talk balloons from the systray. Until you turn them off, which is a few more clicks.
And you still get nagged about Windows Update, even if you are offline (wtf?!? how does it know there are updates available? I got this nag before I ever even connected the machine to the internet). Few more clicks to turn that off.
And you still have MSN messenger running. If you don't use it, few more clicks to turn that off too.
And you still have to turn off that god damned motherfucking filename extension hiding bullshit that has plagued mankind since the days of Windows 95, ARGH!!!!!! Few more clicks to turn that off too (but to be fair Win2K had this problem too).
Bunch of clicks to NOT sign up for Passport when XP was first installed.
Bunch of clicks to do the product activation.
Etc. You can't fix it with "just a few clicks", unless you consider installing w2k to be "just a few clicks".
What Microsoft needs is an Ellen Feiss equivalent. How are they going to get her if they ask for 3 years experience as a computer professional?
"I was using a Mac but, like, my friend's pirated copy of MS Office wouldn't load on it, 'cuz it was the Windows version. And I couldn't get ActiveDirectory to work.
I'm Bob, an MCSE."
I think you're missing the point. This guide is not about building a new system, but upgrading piecemeal. If you just need a bit of a boost and have enough $$$ to spend on a video card or a CPU (but not both), which is the best to upgrade?
Now while I'm no fan of MS, do we really need to have stories everytime someone accueses Microsoft of having poor security?
Yes.
You can blame Microsoft, and you can blame the admins. They are both at fault here. If either of them roles can be fixed, the security problem will be greatly reduced.
Blame Microsoft because the problem is a really lame one. Only so much functionality should be exposed to un-authenticated connections. Really, only authentication should be exposed to un-authenticated users. And that exposed code should be gone over with a microscope, because it is so exposed. If there are bugs in other parts of the system after authentication takes place, that is also bad, but at least it can't easily be used to create a worm. But apparently MS released their product without paying such attention. And it is not the first time.
MS did release a patch. Blame admins for not applying the patch, which has been available for many months.
So now that we've established blame, what can be done to fix things?
There will always be stupid admins. But if we emphatically point the finger at MS when shit like this happens, maybe we can get them to change, and then the stupid admins won't be such a problem for the rest of us.
I recently tried recording a one hour TV show with xawtv, to AVI (MJPEG, 640x480, 15 fps, 16-bit stereo sound). It appeared to record okay, and ended up 5 gigs. But I could only play the first few minutes of it with aviplay. Something (either xawtv, aviplay, or the AVI file format itself) has a 2 (or 4 (unsigned)) GB limit.
Well, those people who were too stupid not to create a revocation certificate, at least.
That's right. As soon as the folks who've been quietly intercepting you communications phone you up and say "Hi, we cracked your RSA key last year, and have been reading your encrypted traffic ever since! Have a nice day!", you should release your revocation certificate.
Kind of like how in WWII Germany realized Enigma had been cracked, and promptly replaced all their Enigma machines with newer models, allowing them to continue to disrupt the Allies' atlantic supply lines and win the war.
</sarcasm>
The write-up is misleading
on
Cross-Site-TRACE
·
· Score: 5, Informative
When misused, TRACE, part of the HTTP protocol, allows an unauthorized script to be passed to a Web server for execution even if the server is secured against running such scripts.
The script is not executed on the server. It is executed on the client.
This is a sort of cross-site scripting vulnerability, not an "execute arbitrary commands on any web server" vulnerability like the writeup suggests.
But what I don't know is where PostgreSQL fits into all of this. I mean, if it IS the better system, why do I only hear mySQL when someone is talking about open source databases?
Because...
MySQL has a commercial entity backing it, that actually makes money selling commercial MySQL licences (the MySQL licence terms are kind of weird, "fully-viral GPL unless you pay us $$$"). This seems to have resulted in some marketoid-speak, which is unusual in the context of an open-source project. For example, "MySQL now supports transactions!" and various other "features", ignoring how fundamental such things are to a real RDBMS and should have always been a part of the design.
There are lots of people who don't understand why you would need "subselects" or "outer joins", and didn't know about "transactions" until they read about it in the mysql change log. And MySQL will be a real RDBMS Real Soon Now (tm) so there's no need to switch to anything else and besides you don't really need a real RDBMS anyway.
Slashdot Mirror
Actually, it's GPL-based. Derivitive works must be distributed under the GPL. By distributing a derivitive work (that includes what is allegedly their code) and claiming that part of it is not GPL, they are violating the GPL, which invalidates any right SCO had to distribute the code he and every other Linux developer wrote.
If the new 2.5 scheduler is the point of contention, that might explain SCO's lack of urgency to cease distribution of their Linux. If the Linux stuff they distributed was 2.4, they weren't leaking their trade secret stuff.
It would also also invalidate the uppity kernel developer's counter-complaint, which is over a 2.4 kernel.
I think he was referring to the flames coming out of the ground. (Took me a second viewing to figure that out.)
"Don't follow the lights. Careful now, or Hobbits go down to join the dead ones and light little candles of their own."
The exorcism scene bothered me the most. It seems that due to time requirements they couldn't have Gandalf go to Isengard to confront Saruman, so they combined the Theodin and Saruman scenes into one. But in doing so, they really hollywood-ized magic in Middle Earth. In the books, mind control magic was subtle yet powerful trickery. Less like The Exorcist and more like manufacturing support for a war in Iraq.
The only problem is, if MP3 or AAC or whatever lossy format fall out of fashion (due to patent or whatever), you could end up with a bunch of files you can't play on the latest gadgets and software. Then you need to re-encode them in whatever the new format, which will add additional lossiness due to the transcoding (unless you re-rip everything, which is a major pain).
If you use a lossless algorithm, you can re-encode to whatever you like. For example, it wouldn't be terribly difficult to take a losslessly-encoded file, decompress it, and run it through a fast MP3 encoder as part of the process of copying the file to your portable. Then if ACC or OGG or whatever displace MP3, you can just change the script when you upgrade your portable.
I agree about the "golden ear" fallacy. Some people avoid lossy because they want "perfect" sound. But there is no "perfect", really... the original recording required sound travelling through air, which is lossy. The recording equipment was also lossy, as is your playback equipment. Your ears and mind are also lossy. Very lossy, in fact... Your ears being lossy is why these lossy audio codecs work as well as they do (they "lose" the parts that your ears/mind would lose anyway).
Except with most/all mail clients for Linux (and probably most mail clients for Windows too; pretty much all of them except MS's) you can't invoke executable content without first saving it, and then going back and explicitly executing it from your shell prompt / Run menu.
You can already declare arrays in-line. So if they were to define an appropriate constructor, you could do List l = new ArrayList(new Object[] { "foo", "bar", "baz" }).
That is verbose of course. What they really should do is add collection manipulation stuff to the language, so you could go List l = ( "foo", "bar", "baz" ) and be done with it.
I believe that that scripting languages get most of their advantages (more functionality with less code, easy to develop in, etc) because they have collections as first-class entities. It's not as if it would be polluting the language... How often do you write code that doesn't use some kind of aggregate data type? For the language to not recognize that is just silly.
Um, no... Microsoft is Mordor. (Duh!)
Sun is Isengard. You know... pretends to be on the side of good, really just wants to betray both sides and set himself up as the new Dark Lord, but in doing so is unwittingly serving Micr^WSauron.
Because if an exception is thrown, you still want the file to be closed.
If you don't find finally useful, you are probably not a defensive coder. Cleanup code (such as calling close()) belongs in a finally block. That way it is sure to be executed, no matter what happens in the try block (barring horrible death of the JVM, power failure, etc). Even if the try block throws an OutOfMemoryError or some other thing you would have no reason to catch, the cleanup code will be called.
If you don't explicitly call close(), the file will still be closed when the garbage collector invokes the destructor, but who knows when that will happen. On some systems with broken filesystem concepts (eg. win32) having an open file will prevent other cleanup operations like delete from working.
Finally is also useful if you simply want to return (or throw) within the try block. Instead of having to duplicate your cleanup code at every point where you return, or do contortions with a "retval" variable and force program flow to pass to the cleanup code before returning, just place the cleanup code in the finally block and place your return statements wherever they naturally belong in the try block. The finally block is guaranteed be invoked as execution leaves the try block, no matter how you leave the try block.
You may know you have a String, but the junior programmer who just came on may not, and will be trying to read your code. All the typecasting in Java is annoying, but it does improve readability. He'll also be writing his own code, and if he thinks he has a String when he doesn't, the compiler will tell him.
That is why Java is so successful. It sacrifices convenience for safety, to protect a probject from inexperienced developers. And while you may not be an inexperienced developer, if you spend any amount of time on large projects you will have to work with them. Better that the language does the hand-holding for the juniors, so the senior developers don't have to (as much).
Sure there is some casting that is clearly redundant, eg. "String name = (String)i.next();". Generics should eliminate those stupid parts.
The whole point of getter/setter methods versus simply making the variable public is to allow other things to happen when the get/set occurs. For example, the return value of the getter method may be generated at call time. Or, maybe you want to fire property change events when the setter method is called (observer pattern, very useful in a model-view-controller structured GUI program (among other things)).
Even if you aren't doing anything fancy, you should use getter/setter methods right from the start, in case you change your mind later. And it's easier to remember to just always use getFoo/setFoo, rather than trying to remember where you need getFoo/setFoo and where you need foo = . With editor macros its not really any extra work to use get/set, so there's no reason not to use the more flexible mechanism.
You should also declare them final: "public static final SenseEnumeration ...". This prevents accidental re-assignment of the field (reports an error at compile-time), and allows the compiler to do some optimizations because it knows the field will never change.
True, but JPEG and GIF don't support alpha blending on any browser, so it's not as if the lack of alpha support in IE is holding people to those older formats.
Still, alpha transparency is a Good Thing, that many web artists would use to good effect if Microsoft would let them. There is a petition to get MS to fix IE.
Java exception verbosity is a serious problem. Many times I've heard of "java.lang" errors. The correct solution to this problem is to use C-style exception handling:
try {
// code
}
catch (Throwable t) {
System.err.println("segfault");
}
As you can see, Java is every bit as good as C.
I think it's good that he took the money. It's $2M that won't be spent on death and destruction.
For those who are just tuning in...
Back in the mid 90s, when Java hype was at its thickest, some hypesters openly proclaimed that Java would kill Microsoft. And the Dark Lord himself quailed in fear: "This scares the hell out of me."
So, MS responded in a way that only MS could. They used their OS monopoly to neutralize the competitor. MS killed Netscape, leaving IE as the only viable middleware platform. Then they created (and shipped with IE/Windows) their own polluted JRE to fuck with the Java specification.
This gave MS time to develop .NET, which will (among other things) provide an applet capability to replace ActiveX (which has an ass-sucking security model compared to Java).
So have patience, SkyLeach. In a few years everyone will be running some version of Internet Explorer with a .NET CLR. You will be able to write your program in any .NET enabled language and it will run on all those systems.
So you'll have your applet technology. You can have any technology you want, as long as you're willing to wait years for MS to wrest control and approve it.
Except it doesn't look exactly like Win2k. The individual UI elements go back to looking like Win2K, but button placement menu structure and such are all still XP.
And you still get those annoying talk balloons from the systray. Until you turn them off, which is a few more clicks.
And you still get nagged about Windows Update, even if you are offline (wtf?!? how does it know there are updates available? I got this nag before I ever even connected the machine to the internet). Few more clicks to turn that off.
And you still have MSN messenger running. If you don't use it, few more clicks to turn that off too.
And you still have to turn off that god damned motherfucking filename extension hiding bullshit that has plagued mankind since the days of Windows 95, ARGH!!!!!! Few more clicks to turn that off too (but to be fair Win2K had this problem too).
Bunch of clicks to NOT sign up for Passport when XP was first installed.
Bunch of clicks to do the product activation.
Etc. You can't fix it with "just a few clicks", unless you consider installing w2k to be "just a few clicks".
"I was using a Mac but, like, my friend's pirated copy of MS Office wouldn't load on it, 'cuz it was the Windows version. And I couldn't get ActiveDirectory to work.
I'm Bob, an MCSE."
GF4 MX is good as long as you don't mind upgrading again when the next generation of games are released (which won't be long now)...
John Carmack: "Don't Buy a GeForce4-MX for Doom 3"
I think you're missing the point. This guide is not about building a new system, but upgrading piecemeal. If you just need a bit of a boost and have enough $$$ to spend on a video card or a CPU (but not both), which is the best to upgrade?
Yes.
You can blame Microsoft, and you can blame the admins. They are both at fault here. If either of them roles can be fixed, the security problem will be greatly reduced.
Blame Microsoft because the problem is a really lame one. Only so much functionality should be exposed to un-authenticated connections. Really, only authentication should be exposed to un-authenticated users. And that exposed code should be gone over with a microscope, because it is so exposed. If there are bugs in other parts of the system after authentication takes place, that is also bad, but at least it can't easily be used to create a worm. But apparently MS released their product without paying such attention. And it is not the first time.
MS did release a patch. Blame admins for not applying the patch, which has been available for many months.
So now that we've established blame, what can be done to fix things?
There will always be stupid admins. But if we emphatically point the finger at MS when shit like this happens, maybe we can get them to change, and then the stupid admins won't be such a problem for the rest of us.
I recently tried recording a one hour TV show with xawtv, to AVI (MJPEG, 640x480, 15 fps, 16-bit stereo sound). It appeared to record okay, and ended up 5 gigs. But I could only play the first few minutes of it with aviplay. Something (either xawtv, aviplay, or the AVI file format itself) has a 2 (or 4 (unsigned)) GB limit.
That's right. As soon as the folks who've been quietly intercepting you communications phone you up and say "Hi, we cracked your RSA key last year, and have been reading your encrypted traffic ever since! Have a nice day!", you should release your revocation certificate.
Kind of like how in WWII Germany realized Enigma had been cracked, and promptly replaced all their Enigma machines with newer models, allowing them to continue to disrupt the Allies' atlantic supply lines and win the war.
</sarcasm>
The script is not executed on the server. It is executed on the client.
This is a sort of cross-site scripting vulnerability, not an "execute arbitrary commands on any web server" vulnerability like the writeup suggests.
Because...