In ~25 years, one board with 6 caps that look like they were installed in reverse. It was an industrial motherboard. I plugged it in and they popped and shot flames a couple inches high before smoking out. Totally freaking awesome.
I've also seen the battery in an Amiga 3000 explode and spew acid all over. Lots of little acid-chewed holes in that motherboard.
And once I had the RAM in a Dell PE2650 actually melt. Burned itself black and started to drip. Again, totally freaking awesome.
You know not of what you speak. Google's mail servers, both G-Mail and hosted, had several issues this year with mail being offline for hours at a time.
FreeDOS can boot from a USB stick. I have one at the office for flashing Dell server BIOS images. It boots pretty much in the blink of an eye. Very, very fast.
I'll believe it when they recover from the slashdotting and I have the code on my servers. Last I knew, MAPI required licenses from Microsoft. Can anyone confirm that the GPL version support MAPI access such as Outlook 2003, 2007 and Outlook Anywhere access on PDA and phones?
This isn't hardware they licensed, it is in-house designed stuff. Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
Cry me a river. If they don't consider the Linux/FOSS market big enough to worry about then say so and be done with it. Intel will gladly take their business.
If you're simply saying "this will take time", then fine. As long as they are interested in taking that path, patience is a virtue. However, it wasn't mentioned in the article and I was bringing it up as a possibility. The preferred one, from many perspectives.
This works fine in an environment where VIA makes chips and provides reference driver code under NDA to a system integrator, who then sells a bundle of software and hardware to an end user. In that case the system integrator either pays the royalties and can sell that product, or doesn't pay the royalties and can just sell the hardware without the proprietary software drivers and programs to actually make use of those hardware features.
Now imagine the open source situation for this. If VIA was suddenly selling chips as intermediate products, but also disclosing free player software to make use of that acceleration features? Would that then be a 'consumer product'? Who knows. But it would definitely be distributed to an 'end user' since it's available to anyone who wants to download it.
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
Option 4: A misconfiguration of their server, such as a lazy admin who configured SSH certificate logins but not requiring a password on his workstation.
What I'm saying is if it IS a hole in server security, it could be an indirect and complicated hole. It could be hard to trace exactly what and how. There is a reason many security people don't "fix" compromised servers. Because it is quite possible you will NEVER know 100% of what happened and how. The only way to be certain of future integrity is start from a fresh install of known good sources. Proper forensic analysis can take quite some time.
This seems to be, from reading the Fedora and Red Hat statements, an ongoing investigation. The same way the police don't comment about investigations in progress, Red Hat is keeping mum. Keep in mind, the breach may be very complex and not something that they can confidently say "we understand" without a very detailed analysis.
They announced the issue immediately and took steps. For now, give them the benefit of the doubt that further details will be forthcoming once a proper investigation has been completed.
Hard drives == file systems as far as the everyday person is concerned. I am fully aware of the benefits of XFS's pre-block allocation and things like packed tails (ReiserFS). File defragmentation has a noticeable benefit on Windows machines formatted as either FAT-32 or NTFS. Disk access can be greatly sped up on defragmented volumes. I would not recommend defragmenting a Linux/Unix system at all. Anyone who searches for "Linux disk defragmentation" is going to find more posts basically saying "you'd don't need to do this" than defrag programs.
I was assuming workstations or PCs, where a weekly reboot is something I still recommend to people. Standby mode is great, but reboots are still necessary in the Windows world. There are too many little memory leaks and other issues that are too easily fixed by a "shut it down on Friday before you go home" mentality. Servers are another ballgame totally. People running servers shouldn't be taking random posts on/. as gospel without further research.
Yes, RAM defragmenters are a waste of time. I'd go as far as say "scam", but can't prove it so I didn't. Keep in mind, back in the days of the C-64 and floppy disks you could create SERIAL files and RANDOM files. Just because the disk could be accessed randomly didn't make any two blocks equal in access time. Contiguous is faster because it can be done in one fetch operation. Are you claiming that two commands to get two non-contiguous blocks of memory are as fast as one command to read a single contiguous block? How about 100 to 1? If so, please feel free to provide me with a detailed explanation as I am genuinely curious. But, I'll agree, that for most operations, memory fragmentation is a non-issue. We're talking theoretical here, or at least "not going to affect your home PC or office workstation".
Uptime clocks are wanking material. Scheduled maintenance requires periodic downtime unless you're in the 1% of the population running totally redundant hardware. And while I can't find the link at the moment, I've seen recent studies that say the entire "it is better to leave the machine powered on than reboot" are myths. Take in the entire equation -- in larger organizations it is cheaper in cooling costs and electricity to shut down workstations over weekends and holidays, and rebooting isn't that bad. Heh, it is even LITERALLY "cool".
I have no idea if the products work. RAM does get fragmented, but nothing a quick reboot won't fix. Hard drives need explicit defragmenting, but that scares me with RAM. I don't want Program A trying to move crap around in memory. Actually, I can't even see *how* they work, moving other program's data around. If program B expects to find a data block at $C000, it better be there and not bounced around by some defrag program.
Yes, it would wear the disk out faster, but your original premise is flawed.
Clustering locations would allow for accessing large chunks of data with one fetch, instead of lots of little fetches. If you're old enough, think back to the Blitter on the Amiga and moving contiguous chunks of memory as opposed fragmented blocks.
Remember, RAM can get fragmented just as badly as a hard drive.
After seeing some of the obfuscated coding contests, they could have a function in there that e-mails a hit man and puts a contract out on your entire family. As long as they labeled it "security module" or some such, most people -- good coders or not -- wouldn't recognize it for what it is. There is a difference between "reviewing code" and being able do delve in so deep you grok the essence of the program are two way different things.
Assuming you use the same compiler, same options, same processor target, same version of your toolchain, etc. that might work. There are too many variables for that to realistically happen. At some point, you'll have to just trust them.
Slashdot Mirror
In ~25 years, one board with 6 caps that look like they were installed in reverse. It was an industrial motherboard. I plugged it in and they popped and shot flames a couple inches high before smoking out. Totally freaking awesome.
I've also seen the battery in an Amiga 3000 explode and spew acid all over. Lots of little acid-chewed holes in that motherboard.
And once I had the RAM in a Dell PE2650 actually melt. Burned itself black and started to drip. Again, totally freaking awesome.
Even bullshit can be used for fertilizer.
Let me go out on a ledge here and suggest something radical.
Include a second DVD with your boxed purchase that has those apps on it. Call it "Windows Plus" or something like that.
It depends on how many you can convince her to drink.
...and it never goes down.
You know not of what you speak. Google's mail servers, both G-Mail and hosted, had several issues this year with mail being offline for hours at a time.
FreeDOS can boot from a USB stick. I have one at the office for flashing Dell server BIOS images. It boots pretty much in the blink of an eye. Very, very fast.
I'll believe it when they recover from the slashdotting and I have the code on my servers. Last I knew, MAPI required licenses from Microsoft. Can anyone confirm that the GPL version support MAPI access such as Outlook 2003, 2007 and Outlook Anywhere access on PDA and phones?
This isn't hardware they licensed, it is in-house designed stuff. Are you trying to tell me that they built chips, yet have no documentation on pinouts, low-level register settings or functional hardware blocks? Exactly what did their in-house software team use to develop the reference drivers?
Cry me a river. If they don't consider the Linux/FOSS market big enough to worry about then say so and be done with it. Intel will gladly take their business.
If you're simply saying "this will take time", then fine. As long as they are interested in taking that path, patience is a virtue. However, it wasn't mentioned in the article and I was bringing it up as a possibility. The preferred one, from many perspectives.
This works fine in an environment where VIA makes chips and provides reference driver code under NDA to a system integrator, who then sells a bundle of software and hardware to an end user. In that case the system integrator either pays the royalties and can sell that product, or doesn't pay the royalties and can just sell the hardware without the proprietary software drivers and programs to actually make use of those hardware features.
Now imagine the open source situation for this. If VIA was suddenly selling chips as intermediate products, but also disclosing free player software to make use of that acceleration features? Would that then be a 'consumer product'? Who knows. But it would definitely be distributed to an 'end user' since it's available to anyone who wants to download it.
How about Option #3: Don't provide reference code at all, just properly document the hardware and less the FOSS crowd write their own?
Craigslist never ceases to amaze or amuse. Nothing like being specific. I wonder if he got any takers?
Yeah, but it is the insane ones that makes it worth all the waiting!
Reasonably lucrative, no major time commitment, can be done at home or a hotel room. Hmmmm...think, think, think.
Have you tried an ad on Craigslist? Make sure to post a picture of yourself, along with your "rates". Good luck!
VoIP baby! No long distance charges.
The other end of that wireless device plugs into a wire, which has a MAC and then runs to a switch port.
Option 4: A misconfiguration of their server, such as a lazy admin who configured SSH certificate logins but not requiring a password on his workstation.
What I'm saying is if it IS a hole in server security, it could be an indirect and complicated hole. It could be hard to trace exactly what and how. There is a reason many security people don't "fix" compromised servers. Because it is quite possible you will NEVER know 100% of what happened and how. The only way to be certain of future integrity is start from a fresh install of known good sources. Proper forensic analysis can take quite some time.
This seems to be, from reading the Fedora and Red Hat statements, an ongoing investigation. The same way the police don't comment about investigations in progress, Red Hat is keeping mum. Keep in mind, the breach may be very complex and not something that they can confidently say "we understand" without a very detailed analysis.
They announced the issue immediately and took steps. For now, give them the benefit of the doubt that further details will be forthcoming once a proper investigation has been completed.
I wasn't misinformed, I was sloppy.
Hard drives == file systems as far as the everyday person is concerned. I am fully aware of the benefits of XFS's pre-block allocation and things like packed tails (ReiserFS). File defragmentation has a noticeable benefit on Windows machines formatted as either FAT-32 or NTFS. Disk access can be greatly sped up on defragmented volumes. I would not recommend defragmenting a Linux/Unix system at all. Anyone who searches for "Linux disk defragmentation" is going to find more posts basically saying "you'd don't need to do this" than defrag programs.
I was assuming workstations or PCs, where a weekly reboot is something I still recommend to people. Standby mode is great, but reboots are still necessary in the Windows world. There are too many little memory leaks and other issues that are too easily fixed by a "shut it down on Friday before you go home" mentality. Servers are another ballgame totally. People running servers shouldn't be taking random posts on /. as gospel without further research.
Yes, RAM defragmenters are a waste of time. I'd go as far as say "scam", but can't prove it so I didn't. Keep in mind, back in the days of the C-64 and floppy disks you could create SERIAL files and RANDOM files. Just because the disk could be accessed randomly didn't make any two blocks equal in access time. Contiguous is faster because it can be done in one fetch operation. Are you claiming that two commands to get two non-contiguous blocks of memory are as fast as one command to read a single contiguous block? How about 100 to 1? If so, please feel free to provide me with a detailed explanation as I am genuinely curious. But, I'll agree, that for most operations, memory fragmentation is a non-issue. We're talking theoretical here, or at least "not going to affect your home PC or office workstation".
Uptime clocks are wanking material. Scheduled maintenance requires periodic downtime unless you're in the 1% of the population running totally redundant hardware. And while I can't find the link at the moment, I've seen recent studies that say the entire "it is better to leave the machine powered on than reboot" are myths. Take in the entire equation -- in larger organizations it is cheaper in cooling costs and electricity to shut down workstations over weekends and holidays, and rebooting isn't that bad. Heh, it is even LITERALLY "cool".
I feel compelled to print many quantities of that tract and leave them on windshields and in restaurants.
Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!
sigh... .Net is pants.
Better?
I have no idea if the products work. RAM does get fragmented, but nothing a quick reboot won't fix. Hard drives need explicit defragmenting, but that scares me with RAM. I don't want Program A trying to move crap around in memory. Actually, I can't even see *how* they work, moving other program's data around. If program B expects to find a data block at $C000, it better be there and not bounced around by some defrag program.
I personally wouldn't waste my time on them.
Yes, it would wear the disk out faster, but your original premise is flawed.
Clustering locations would allow for accessing large chunks of data with one fetch, instead of lots of little fetches. If you're old enough, think back to the Blitter on the Amiga and moving contiguous chunks of memory as opposed fragmented blocks.
Remember, RAM can get fragmented just as badly as a hard drive.
You'll just be saved for last, like an after-dinner mint. Its a good thing. Trust me. :-)
May Cthulhu bless you!
I didn't even think to add the S there and try that!
Meh.
After seeing some of the obfuscated coding contests, they could have a function in there that e-mails a hit man and puts a contract out on your entire family. As long as they labeled it "security module" or some such, most people -- good coders or not -- wouldn't recognize it for what it is. There is a difference between "reviewing code" and being able do delve in so deep you grok the essence of the program are two way different things.
Assuming you use the same compiler, same options, same processor target, same version of your toolchain, etc. that might work. There are too many variables for that to realistically happen. At some point, you'll have to just trust them.