How so, exactly? This ruling will result in the current situation persisting for some time. The change would have been if they had ruled that SCC couldn't manufacture generic refills. The aftermarket has always jumped through all the hoops that the OEMs set, and this is just another example. Every printer manufacturer has been dealing with this for years, and will continue to deal with it in the same way into the future. They will try to make funky or bizarre ink/toner containers, and the aftermarket will continue to duplicate them. Nothing changes...
In fact there's a whole bunch of things you can do with the ANSI escape sequences. All you have to do is use \e for ESC (or \033 if octal is your thing.) bash also includes the \[ and \] meta-escape characters that you put around non-printing escape sequences to let the shell know that they're non-printing.
My bash prompt is currently: PS1='\[\e]0;\l \w\007\]\n($?) \t \[\e[36m\]\l \[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n$ '
The "ESC]0;foo\007" bit sets the rxvt terminal title to the current tty and path. $? is the exit code of the last command, \t is the time, \l is the tty, \u is the user name, \h is the hostname, \w is the CWD. (All of these are in the bash info pages.)
No, but what will cost a fortune is that the government will require the entire surplus inventory of spare unused RFID tags to each have their own RFID tag, which in turn are themselves RFID-tagged, and so on.
Sodium also is a very good conductor of heat, it was no coincidence that they chose it for this purpose. This same trick is used in the stem of exhaust valves in a lot of automobile engines. The exhaust valve is often the hottest part of the entire engine because it is immersed in the hot gas right after combustion, during the period that the valve is open. It's a relatively small part and is nearly completely immersed in this very hot gas. The only paths for heat to leave the valve is through the narrow stem, and through the valve seat in the head when the valve is closed and seated. This also explains why you will burn a valve if you manually adjust the clearance of your lifters and leave too little free-play. If the valve doesn't seat all the way it will have very poor heat conduction.
Anyway, to aid the heat transfer down the valve stem, often the core is filled with sodium. I believe it does the same phase-change convection cycle as mentioned in this article, where the sodium is heated at the hot end and rises to the cool end and then back again, improving the process of removing heat from the valve.
"The word 'nuclear' makes me nervous," said Randy Virgin of the Alaska Center for the Environment.
He then went on to say "Yeah, I've got to get going, I've got to meet my friends Craven Morehead and Wouldja Blowme, we're going to go to the mall and chill for a while..."
How the fuck is this "Informative"? How about "-1, Wrong". No such thing happens on my system nor on any properly installed windows system. If holding down the mouse button takes 100% CPU then something is seriously wrong with your setup.
When this happens to me, I find that hitting back results in an empty form without my long message... But if you then hit Forward, it will ask you if you want to repost the form data (which you do) and it will successfully add the post, assuming the server doesn't give a 500 again. I think reloading does the same thing (asking if you want to repost), but if it doesn't you can try back+forward.
Riiiight, and so when the next OpenSSH (or Squid, Apache, proftpd, whatever) vulnerability is announced, you're supposed to just start over from scratch?
I understand the idea that you don't want dev tools on an externally accessable machine. But, at the same time, you either need some kind of binary package management, or you need to have the ability to do a "make world" on another box and copy over the binaries.
I think this whole XML thing is a red herring. I think what they mean by "incorporate features of XML" is that the filesystem will support an extensible set of metadata fields for each file. So where currently you have creation time, modification time, security attributes, etc. in the new FS you will be able to define and store any arbitrary metadata attribute for a file... For example, take images: you could enter a description of what's in the picture and it would be stored with the file. These attributes might even be described by an XML schema and stored in an XML format, but that doesn't mean the filesystem uses XML for its underlying structure. You could imagine the case of having "mypicture.jpg" and "mypicture-metadata.xml", where the latter contains the metadata for the former... and instead of storing this as two files, the filesystem keeps track of the two under a single "entry" in the filesystem. So when you want to access the payload, or the main binary data, it would be handled the same as NTFS does now. But the XML metadata is also indexed somewhere, so when you want to search the description tag for some keyword, it will also be able to find mypicture.jpg. You could probably hack something like this together with NTFS, by using the "alternate streams" or whatever it's called that lets you store extra/alternative file data in the filesystem.
I don't think anyone from MS has ever said that they are thinking of using XML as the actual underlying engine of the filesystem. That would be really stupid. Just think of this as taking the current existing "file attributes" and storing them in XML alongside the regular file's contents.
- It will cost about $10 to $25 a year extra, depending on your energy costs and CPU model.
- I would argue that things like your screensaver settings (and whether your monitor powers down) have just as much of an effect on the energy bill as the CPU. This assumes you use a CRT, as it probably doesn't matter much for a LCD.
- Depending on your climate, it may not matter one bit as that electricity is converted to heat anyway. If you're using electricity to heat your home then it's probably a wash.
- Any premature failures will most likely be due to cheap or inadequate cooling, such as fan bearings losing lubrication and failing, or too much accumulated dust. In other words, it's probably a good idea to fix those deficiencies anyway... If distributed computing brings them to your attention then it could even be a beneficial thing.
Conclusion:
Run distributed computing if you think it's worthwhile, but don't lose too much sleep over it breaking things or costing you a lot of money.
I would like to start a "Burn SunComm to the ground and plough the land under with salt" fund. I wonder whether that would qualify as a "good" or a "service" under the PayPal rules...
It probably made sense to them, but it's the exact wrong thing to do, and I don't mean that in the typical 'information wants to be free' Slashdot philosophy.
Rather, history has proved time and time again that if someone has published information that you DO NOT WANT others to know about, the LAST thing you want to do is sue them or get an injunction. Almost without fail, this draws a great deal of attention to your case, and invariably causes a backlash that results in your "secret info" being MORE available than it would have been if you had just let it be.
For example, here's a perfect case of this in action: the Streisand coastal photos fiasco. To summarize, someone wanted to take high resolution digital photos from a helicopter of the entire California coastline. It just so happens that a photo of Streisand's beachfront property was included in this archive. She sued for $50 million dollars to try to get this hires photo of the backside of her house removed on the grounds of privacy or somesuch, even though it didn't show any people or really anything interesting at all.
The end result? That photo was downloaded SIX times in the three months prior to the lawsuit. However, after the lawsuit was publicised, the photo was averaging 108,000 hits per day. (source)
Don't you think this idiotic case will have the same effect? If you don't want people to know how easy your protections are to break, the LAST thing you want to do is go and sue an otherwise harmless college nerd who published an examination of the flaws of your product. That can only have the opposite effect, to get the word out to MORE people of how bad your software is. And they can't seriously think that they will be able to put this genie back in the bottle. Even if they order the researcher and/or Princeton to take down the report, it will surely be mirrored by countless livid netizens. Would the DeCSS algorithm exist on so many servers in so many forms if someone hadn't made such a stink about it? And the publicity surrounding such barratry can only have a negative effect on how people view your company. STUPID. STUPID. STUPID.
Heh... that's hilarious. It almost sounds like they got MojoJojo to do the voice over. Now that would rock.
And sunncomm's site? Holy jesus, that's ugly. It looks like one of those garish monstrosities from when the web was first blessed with the "<blink>" tag. How could anyone take that flashy garbage seriously?
And I really want to know if there's like a class or something that everyone takes in design school, titled "How to use stock pictures of overenthusiastic women with fisheye distortion to sell your product." It seems to be a staple of crappy ad copy, the "hot chick" in a distorted picture that overemphasises the tired, fake facial expression.
Did anyone notice this on their project homepage link at sourceforge:
JourneyOS has been temporarily shut down
Following our recent publicity on a major news site, we have been politely requested to refrain from using the copyrighted material of the band Journey and their respective record labels. We have also been warned of possible future legal complications from using Journey album names and for the components of our project and using pseudonyms derived from the band members' names.
Furthermore, we have been notified of some inherent design flaws in one of the core mechanisms of JourneyOS, which was to be used as part of our upcoming GUI system. We have received proof-of-concept code showing that use of the IA32 memory segmentation mechanism for IPC is an inherently dangerous practice, and consequently is not suitable for a general purpose operating system.
We would like to thank you all for the newfound support and encouragement in our quest to create a proactively modern operating system. Unfortunately due to the sheer volume of mail we received we will be unable to reply to you all personally. However, if you would like to remain informed about what we are doing, we ask that you subscribe to the project mailing list where we will discuss where to go from here in the realm of JourneyOS development.
Thank you for your patience and support - jc
So, just in case there was any doubt that this entire project was entirely vaporware...
I don't know about you but this article had a hint of sensationalist feel to it, like those TV blurbs: "Breaking News! Your every move tracked! (Tune in at 11 for details)"
The fact is cookies are a very widely used thing, and to paint the picture of google somehow being underhand for "secretly installing this counter on millions of hard drives" is a bit of a stretch. For one thing, it's optional: you can configure most browsers to disallow or block cookies. And it's hardly unique to google, I bet you couldn't find a major media/news web site out there that doesn't use cookies in some form or another. You probably have hundreds of them in your cookie jar, unless you've diabled them in your browser.
And then to equate this to spying? That would be like saying, "Company Foo installed a closed-circuit camera in their lobby! OMG! They can tell everywhere you've been inside their building!" The whole cookie exchange is based on the browser voluntarily accepting it when contacting a server, there's really nothing underhanded about it. And the rules of how cookies work were devised specifically in such a way so that "domain.com" only has access to cookies set for "domain.com" and its subdomains. So the only thing they're tracking is your use of their server, which they already have the logs for anyway.
What's next, some reporter stumbles onto the 'Referer' and 'User-Agent' fields in the HTTP headers, and writes some garbage piece about how "Internet sites secretly know where you came from when you load their page! ANd they know what operating system and browser you use! It's a giant conspiracy, your privacy is at stake!"
I don't think you understand. Here's what's happening.
1. ReallyCoolSite.com goes live. 2. archive.org spiders ReallyCoolSite.com and stores a snapshot, because ReallyCoolSite has allowed this in its robots.txt. 3. much time passes, ReallyCoolSite.com goes offline and the domain expires. 4. the archive.org spider goes to check ReallyCoolSite.com. Where before it would have gotten a NXDOMAIN error and stopped there, it now sees a site and this new site has a robots.txt that says "go away all robots." It has no way of knowing that this new site is not the same as ReallyCoolSite.com, and so it removes all links to its archived copies of ReallyCoolSite.com, as it thought that ReallyCoolSite.com has now changed its robots.txt policy.
Now anyone who wants to see old copies of that site cannot because of VeriSlime.
Jees, that sounds rather forced... What ever happened to "come to class, listen to the lecturer, and occasionally take this 10 minute written quiz to encourage you to come every day." Do they also prop open your eyelids (ala A Clockwork Orange) to make sure you don't take a nap?
Interesting point. It's a good thing that regular snail mail delivery doesn't expose your mail to hundreds or thousands of people with low paid labor-intensive jobs. Oh wait, it does.
Sorry, I agree about the electronic issues (i.e. email not being secure) but your snail mail passes through MANY hands and has far more opportunities to be physically stolen or opened. It even sits right there out in the open in your mailbox for several hours.
You must get tired of picking up the phone and whistling at 300 buad into the receiver then... and how you get around Slashdot's formkeys is beyond me.
I agree with the fact that you will be better off knowing the standards, and that this will help you when designing solutions, etc. However, when it comes down to actually writing the code, all those abstractions are there to help you. Everyone SHOULD depend on them, because they are very likely to have COMPLETE support for every requirement of the standards and for special cases. If you sit down and write CGI programs "gonzo style" from scratch without using the abstractions provided you are very likely to at best write code that is buggy under odd circumstances and at worst contains gaping security holes.
You see this all the time, where someone that knows perl relatively well sites down to write a CGI program and rather than using the very robust and complete CGI.pm they decide "Aww, I know how HTTP works, I don't need any of that junk." So they write scripts that do everything with "print" statements (<cough> matt's-script-archive) and it turns out that these scripts are often broken under certain odd circumstances, or they have all sorts of security issues. If the person had just said "I don't know the nitty gritty of HTTP and I don't care, I'll let CGI.pm handle that" then they would have had a must lower chance of running into those issues.
Soooo, what you're saying is the editors don't read the stories? And because of the constant dupes, apparently they don't read slashdot either. So we can logically conclude that the process of "editing" must therefore amount to randomly clicking "accept" and "reject" links, and looking busy.
Slashdot Mirror
How so, exactly? This ruling will result in the current situation persisting for some time. The change would have been if they had ruled that SCC couldn't manufacture generic refills. The aftermarket has always jumped through all the hoops that the OEMs set, and this is just another example. Every printer manufacturer has been dealing with this for years, and will continue to deal with it in the same way into the future. They will try to make funky or bizarre ink/toner containers, and the aftermarket will continue to duplicate them. Nothing changes...
There certainly is...
For the love of god, stop using that non-word "virii". The plural of virus is viruses.
In fact there's a whole bunch of things you can do with the ANSI escape sequences. All you have to do is use \e for ESC (or \033 if octal is your thing.) bash also includes the \[ and \] meta-escape characters that you put around non-printing escape sequences to let the shell know that they're non-printing.
My bash prompt is currently:
PS1='\[\e]0;\l \w\007\]\n($?) \t \[\e[36m\]\l \[\e[32m\]\u@\h \[\e[33m\]\w\[\e[0m\]\n$ '
The "ESC]0;foo\007" bit sets the rxvt terminal title to the current tty and path. $? is the exit code of the last command, \t is the time, \l is the tty, \u is the user name, \h is the hostname, \w is the CWD. (All of these are in the bash info pages.)
No, but what will cost a fortune is that the government will require the entire surplus inventory of spare unused RFID tags to each have their own RFID tag, which in turn are themselves RFID-tagged, and so on.
Sodium also is a very good conductor of heat, it was no coincidence that they chose it for this purpose. This same trick is used in the stem of exhaust valves in a lot of automobile engines. The exhaust valve is often the hottest part of the entire engine because it is immersed in the hot gas right after combustion, during the period that the valve is open. It's a relatively small part and is nearly completely immersed in this very hot gas. The only paths for heat to leave the valve is through the narrow stem, and through the valve seat in the head when the valve is closed and seated. This also explains why you will burn a valve if you manually adjust the clearance of your lifters and leave too little free-play. If the valve doesn't seat all the way it will have very poor heat conduction.
Anyway, to aid the heat transfer down the valve stem, often the core is filled with sodium. I believe it does the same phase-change convection cycle as mentioned in this article, where the sodium is heated at the hot end and rises to the cool end and then back again, improving the process of removing heat from the valve.
How the fuck is this "Informative"? How about "-1, Wrong". No such thing happens on my system nor on any properly installed windows system. If holding down the mouse button takes 100% CPU then something is seriously wrong with your setup.
When this happens to me, I find that hitting back results in an empty form without my long message... But if you then hit Forward, it will ask you if you want to repost the form data (which you do) and it will successfully add the post, assuming the server doesn't give a 500 again. I think reloading does the same thing (asking if you want to repost), but if it doesn't you can try back+forward.
Riiiight, and so when the next OpenSSH (or Squid, Apache, proftpd, whatever) vulnerability is announced, you're supposed to just start over from scratch?
I understand the idea that you don't want dev tools on an externally accessable machine. But, at the same time, you either need some kind of binary package management, or you need to have the ability to do a "make world" on another box and copy over the binaries.
I think this whole XML thing is a red herring. I think what they mean by "incorporate features of XML" is that the filesystem will support an extensible set of metadata fields for each file. So where currently you have creation time, modification time, security attributes, etc. in the new FS you will be able to define and store any arbitrary metadata attribute for a file... For example, take images: you could enter a description of what's in the picture and it would be stored with the file. These attributes might even be described by an XML schema and stored in an XML format, but that doesn't mean the filesystem uses XML for its underlying structure. You could imagine the case of having "mypicture.jpg" and "mypicture-metadata.xml", where the latter contains the metadata for the former... and instead of storing this as two files, the filesystem keeps track of the two under a single "entry" in the filesystem. So when you want to access the payload, or the main binary data, it would be handled the same as NTFS does now. But the XML metadata is also indexed somewhere, so when you want to search the description tag for some keyword, it will also be able to find mypicture.jpg. You could probably hack something like this together with NTFS, by using the "alternate streams" or whatever it's called that lets you store extra/alternative file data in the filesystem.
I don't think anyone from MS has ever said that they are thinking of using XML as the actual underlying engine of the filesystem. That would be really stupid. Just think of this as taking the current existing "file attributes" and storing them in XML alongside the regular file's contents.
So, in summary:
- It will cost about $10 to $25 a year extra, depending on your energy costs and CPU model.
- I would argue that things like your screensaver settings (and whether your monitor powers down) have just as much of an effect on the energy bill as the CPU. This assumes you use a CRT, as it probably doesn't matter much for a LCD.
- Depending on your climate, it may not matter one bit as that electricity is converted to heat anyway. If you're using electricity to heat your home then it's probably a wash.
- Any premature failures will most likely be due to cheap or inadequate cooling, such as fan bearings losing lubrication and failing, or too much accumulated dust. In other words, it's probably a good idea to fix those deficiencies anyway... If distributed computing brings them to your attention then it could even be a beneficial thing.
Conclusion:
Run distributed computing if you think it's worthwhile, but don't lose too much sleep over it breaking things or costing you a lot of money.
I would like to start a "Burn SunComm to the ground and plough the land under with salt" fund. I wonder whether that would qualify as a "good" or a "service" under the PayPal rules...
It probably made sense to them, but it's the exact wrong thing to do, and I don't mean that in the typical 'information wants to be free' Slashdot philosophy.
Rather, history has proved time and time again that if someone has published information that you DO NOT WANT others to know about, the LAST thing you want to do is sue them or get an injunction. Almost without fail, this draws a great deal of attention to your case, and invariably causes a backlash that results in your "secret info" being MORE available than it would have been if you had just let it be.
For example, here's a perfect case of this in action: the Streisand coastal photos fiasco. To summarize, someone wanted to take high resolution digital photos from a helicopter of the entire California coastline. It just so happens that a photo of Streisand's beachfront property was included in this archive. She sued for $50 million dollars to try to get this hires photo of the backside of her house removed on the grounds of privacy or somesuch, even though it didn't show any people or really anything interesting at all.
The end result? That photo was downloaded SIX times in the three months prior to the lawsuit. However, after the lawsuit was publicised, the photo was averaging 108,000 hits per day. (source)
Don't you think this idiotic case will have the same effect? If you don't want people to know how easy your protections are to break, the LAST thing you want to do is go and sue an otherwise harmless college nerd who published an examination of the flaws of your product. That can only have the opposite effect, to get the word out to MORE people of how bad your software is. And they can't seriously think that they will be able to put this genie back in the bottle. Even if they order the researcher and/or Princeton to take down the report, it will surely be mirrored by countless livid netizens. Would the DeCSS algorithm exist on so many servers in so many forms if someone hadn't made such a stink about it? And the publicity surrounding such barratry can only have a negative effect on how people view your company. STUPID. STUPID. STUPID.
Heh... that's hilarious. It almost sounds like they got MojoJojo to do the voice over. Now that would rock.
And sunncomm's site? Holy jesus, that's ugly. It looks like one of those garish monstrosities from when the web was first blessed with the "<blink>" tag. How could anyone take that flashy garbage seriously?
And I really want to know if there's like a class or something that everyone takes in design school, titled "How to use stock pictures of overenthusiastic women with fisheye distortion to sell your product." It seems to be a staple of crappy ad copy, the "hot chick" in a distorted picture that overemphasises the tired, fake facial expression.
So, just in case there was any doubt that this entire project was entirely vaporware...
I don't know about you but this article had a hint of sensationalist feel to it, like those TV blurbs: "Breaking News! Your every move tracked! (Tune in at 11 for details)"
The fact is cookies are a very widely used thing, and to paint the picture of google somehow being underhand for "secretly installing this counter on millions of hard drives" is a bit of a stretch. For one thing, it's optional: you can configure most browsers to disallow or block cookies. And it's hardly unique to google, I bet you couldn't find a major media/news web site out there that doesn't use cookies in some form or another. You probably have hundreds of them in your cookie jar, unless you've diabled them in your browser.
And then to equate this to spying? That would be like saying, "Company Foo installed a closed-circuit camera in their lobby! OMG! They can tell everywhere you've been inside their building!" The whole cookie exchange is based on the browser voluntarily accepting it when contacting a server, there's really nothing underhanded about it. And the rules of how cookies work were devised specifically in such a way so that "domain.com" only has access to cookies set for "domain.com" and its subdomains. So the only thing they're tracking is your use of their server, which they already have the logs for anyway.
What's next, some reporter stumbles onto the 'Referer' and 'User-Agent' fields in the HTTP headers, and writes some garbage piece about how "Internet sites secretly know where you came from when you load their page! ANd they know what operating system and browser you use! It's a giant conspiracy, your privacy is at stake!"
I don't think you understand. Here's what's happening.
1. ReallyCoolSite.com goes live.
2. archive.org spiders ReallyCoolSite.com and stores a snapshot, because ReallyCoolSite has allowed this in its robots.txt.
3. much time passes, ReallyCoolSite.com goes offline and the domain expires.
4. the archive.org spider goes to check ReallyCoolSite.com. Where before it would have gotten a NXDOMAIN error and stopped there, it now sees a site and this new site has a robots.txt that says "go away all robots." It has no way of knowing that this new site is not the same as ReallyCoolSite.com, and so it removes all links to its archived copies of ReallyCoolSite.com, as it thought that ReallyCoolSite.com has now changed its robots.txt policy.
Now anyone who wants to see old copies of that site cannot because of VeriSlime.
Are you implying that I shouldn't trust the timecube guy?
Jees, that sounds rather forced... What ever happened to "come to class, listen to the lecturer, and occasionally take this 10 minute written quiz to encourage you to come every day." Do they also prop open your eyelids (ala A Clockwork Orange) to make sure you don't take a nap?
Interesting point. It's a good thing that regular snail mail delivery doesn't expose your mail to hundreds or thousands of people with low paid labor-intensive jobs. Oh wait, it does.
Sorry, I agree about the electronic issues (i.e. email not being secure) but your snail mail passes through MANY hands and has far more opportunities to be physically stolen or opened. It even sits right there out in the open in your mailbox for several hours.
You must get tired of picking up the phone and whistling at 300 buad into the receiver then... and how you get around Slashdot's formkeys is beyond me.
I agree with the fact that you will be better off knowing the standards, and that this will help you when designing solutions, etc. However, when it comes down to actually writing the code, all those abstractions are there to help you. Everyone SHOULD depend on them, because they are very likely to have COMPLETE support for every requirement of the standards and for special cases. If you sit down and write CGI programs "gonzo style" from scratch without using the abstractions provided you are very likely to at best write code that is buggy under odd circumstances and at worst contains gaping security holes.
You see this all the time, where someone that knows perl relatively well sites down to write a CGI program and rather than using the very robust and complete CGI.pm they decide "Aww, I know how HTTP works, I don't need any of that junk." So they write scripts that do everything with "print" statements (<cough> matt's-script-archive) and it turns out that these scripts are often broken under certain odd circumstances, or they have all sorts of security issues. If the person had just said "I don't know the nitty gritty of HTTP and I don't care, I'll let CGI.pm handle that" then they would have had a must lower chance of running into those issues.
The rest of them couldn't really say for sure if they'd ever played GTA, on account of the head trauma from all that fighting.
Soooo, what you're saying is the editors don't read the stories? And because of the constant dupes, apparently they don't read slashdot either. So we can logically conclude that the process of "editing" must therefore amount to randomly clicking "accept" and "reject" links, and looking busy.