At this point C could now have a new value after the C++ operation. This is not defined by the standard AFAIK. The correct way is not to write it at all, because why the hell would you need that in sane code.
Red Hat funds a lot of open source development, including a number of their own initiatives. So their existence depended on a lot of open source, but they're helping keep the ecosystem alive now that they do exist.
Whether or not all of the claims in Guttman's article are true (and I agree that a few are obviously based on miscommunication in Microsoft's own documentation), it is clearly evident that Vista is a lot more heavyweight than XP without really offering anything. Now either a large chunk of that is DRM, or a small chunk is DRM and the rest is sheer unmitigated engineering failure. Either way it's bad. Whatever they're doing to fix Windows 7 is very welcomed and it looks like they've learned their lesson, but we can't claim Vista doesn't suck just because some of the reasons it sucks aren't completely valid, because there are plenty of other reasons it does still suck.
Unlike Windows, if you install a very lean Linux distribution, even one with up-to-date package versions, it will be absurdly fast as you'd expect from modern hardware. Just because Ubuntu is being burdened doesn't mean the FOSS landscape itself is.
The algorithms and data structures in almost all open source applications have either stayed the same over the years, or gotten better, with the notable exception of some programs like GCC which have used the increase in system resources to advance compiled code optimisation rather than compile-time performance.
This whole "of course newer is slower" thing is just Microsoft brain damage. Apple is another company which regularly improves performance and scalability in its software products, even with DRM problems similar to Vista.
Did you know that by now hundreds/thousands of Windows *system* *calls* have built-in backwards compatibility checks to support programs whose source code is not available for maintenance? You're paying a performance penalty every time you make a system call, with no option to turn it off, just because someone somewhere might want to play The Sims. Open source solves this problem by fixing the program, rather than hacking every layer of the OS to support old bugs. You can't spell "backwards compatibility" without "backward".
I am very confused as to why this should apply to something like e.g. a C compiler. Why would anything but a media decoder/player/encoder require media DRM? Last I checked C compilers don't require kernel DRM support to detect copyright violations in source code. Although looking at how big and slow Visual Studio has gotten over time, I wouldn't be surprised.
These days you can just use iSCSI to any free Unix-like and export a memory-backed virtual disk. It's also a nice way to use one machine's memory as swapspace for another, and with a fast network link it's like having more RAM in the client machine.
What masterful release are you talking about? Windows 7 isn't even out yet. If you're going to prepare trolls in advance at least make sure you don't post them too early.
I confirm that Load Cycle Count on *all* of my laptops and even some old hard disk drives will go from changing dozens of times per hour to once per power up, if hdparm is given -B254. The audible click is, well, audible, so it's a mechanical process.
One of my very old laptop disks ran down to malfunction over years of running Slackware, Gentoo, FreeBSD, NetBSD, whatever you can name, and they all contributed to the problem whenever I did not disable the disk's default power management.
Debian Lenny and Ubuntu Intrepid both force sane power management out of the box, even on a text-only install. I consider the problem solved.
If Microsoft had been even remotely competent they would have included at least two checksums for each file, so that once you downloaded them from an untrusted source, the file becomes trusted by verifying all of its checksums. Just one checksum may be cracked but two in different algorithms are much less likely.
30 MB/s is your idea of fast file copying? On Linux I get 20 just off old external hard drives, 40-50 with eSATA on 2.5"s, and 70+ on any modern 3.5". What the hell is Vista doing that makes file copies so slow? Read block, write block. Where is all that overhead coming from such that you're getting less than 50% of my throughput just because you booted Vista?
He means it runs on a set of computer types which has a higher cardinality than Vista's. Linux natively runs on architectures that no Windows has never even been emulated on, let alone run natively. Now embedded + desktop + server hardware is almost all coming together as x86, so Windows is no longer at such a disadvantage, but what he said about the current number of types of machines Linux running on is correct.
Only if *everyone* alive is a member of the Master Race will life become simpler.
You know I've even heard there are entire operating systems other than Windows? That there are CPU architectures other than x86? If you're the kind of developer who refuses to support every operating system except Win64, supporting Win32 would be only slightly less of a crime.
Windows can hardly manage 10,000 system calls per second. You'd be very lucky to even get 1000 game logic updates per second on a *realtime* system, let alone a userland thread with syscall based locking, which again is all Windows has. 100 is much more reasonable.
Nope - thanks for the update. SSD will only defeat software file shredders if run through an FTL (which most are, but we should be moving away from this). However if your flash-optimised file system like ubifs does rotating writes then once again a file shredder is useless and will just waste erase blocks.
Ideally you'd just use block level encryption before writing the data in the first place. For years now it has been very easy to set up a volume manager (lvm, gvinum,...) over an encrypted volume (device-mapper, geli) over software raid (md, gmirror) on server-class operating systems like Linux and FreeBSD. You get volume management, RAID and encryption, at the cost of entering a password and some ever-shrinking performance penalty.
I know you're trolling and probably high as a kite being flown by another kite, but just in case anyone takes you seriously, let it be known that file shredding is not a kernel's job, and using a non-journalled filesystem (or a journalled filesystem set to not journal data blocks) will allow file shredders to work just fine.
However, a pass of zeroes is not enough as some magnetic domains will remain in their old state and allow partial data recovery.
ZFS RAID1 (and RAID-Z and RAID-Z2) can heal over corrupted blocks from the redundant copy. This is not possible with hardware RAID since it doesn't know which copy is valid.
Try to run a webserver with caching built in. Chances are good 295 of those 300 files are going to be reloaded per page and can be stored in memory indefinitely. Last I heard, memory is still faster than SSD.
Windows 7 has new CPU scheduling, a revised WDDM, a revised DWM, I/O and kernel level locks removed, a new event based Service model (reducing RAM footprint), new low latency push/pull sound processing, and then starts adding end user features and upper level OS integration of features.
That sounds like what gets changed every 3-6 months in a Linux distribution like Ubuntu or Fedora. Are you suggesting that even after 2 years of full time work Microsoft can only make such small incremental improvements to Vista?
Hell, even the short changelog of the Linux kernel itself is more impressive once every ~3 months. What is Microsoft wasting so much time on?
What poor algorithm? Hash collisions aside, a password is a password. Only things like retry limits, retry delays, automatic blacklisting, etc. will make any difference, and as we've agreed, these are matters of configuration which must be identical between systems for any meaningful comparison.
Regardless of what kernel is running, a password auth's security hinges on the password. Yes, for Windows it's probably even easier to probe SMB or IIS, but the password auth will be just as good or bad as OpenBSD if configured the same.
So, Mr Formal Education In Operating Systems, will OpenBSD refuse a valid username and password combination because the person logging in has a hidden evil deep in their hearts, unlike Windows which has blind faith in all valid passwords?
You're very confused. It's true that, if configured to accept username and password authentication, any system will treat a valid username and password as sufficient. That's why most professional administrators use public key authentication with good private key protection policies. But given an equal configuration of username and password, OpenBSD will be just as trusting as Windows.
It could be evaluated thus:
C++
C
!=
At this point C could now have a new value after the C++ operation. This is not defined by the standard AFAIK. The correct way is not to write it at all, because why the hell would you need that in sane code.
Red Hat funds a lot of open source development, including a number of their own initiatives. So their existence depended on a lot of open source, but they're helping keep the ecosystem alive now that they do exist.
Whether or not all of the claims in Guttman's article are true (and I agree that a few are obviously based on miscommunication in Microsoft's own documentation), it is clearly evident that Vista is a lot more heavyweight than XP without really offering anything. Now either a large chunk of that is DRM, or a small chunk is DRM and the rest is sheer unmitigated engineering failure. Either way it's bad. Whatever they're doing to fix Windows 7 is very welcomed and it looks like they've learned their lesson, but we can't claim Vista doesn't suck just because some of the reasons it sucks aren't completely valid, because there are plenty of other reasons it does still suck.
Unlike Windows, if you install a very lean Linux distribution, even one with up-to-date package versions, it will be absurdly fast as you'd expect from modern hardware. Just because Ubuntu is being burdened doesn't mean the FOSS landscape itself is.
The algorithms and data structures in almost all open source applications have either stayed the same over the years, or gotten better, with the notable exception of some programs like GCC which have used the increase in system resources to advance compiled code optimisation rather than compile-time performance.
This whole "of course newer is slower" thing is just Microsoft brain damage. Apple is another company which regularly improves performance and scalability in its software products, even with DRM problems similar to Vista.
Did you know that by now hundreds/thousands of Windows *system* *calls* have built-in backwards compatibility checks to support programs whose source code is not available for maintenance? You're paying a performance penalty every time you make a system call, with no option to turn it off, just because someone somewhere might want to play The Sims. Open source solves this problem by fixing the program, rather than hacking every layer of the OS to support old bugs. You can't spell "backwards compatibility" without "backward".
I am very confused as to why this should apply to something like e.g. a C compiler. Why would anything but a media decoder/player/encoder require media DRM? Last I checked C compilers don't require kernel DRM support to detect copyright violations in source code. Although looking at how big and slow Visual Studio has gotten over time, I wouldn't be surprised.
These days you can just use iSCSI to any free Unix-like and export a memory-backed virtual disk. It's also a nice way to use one machine's memory as swapspace for another, and with a fast network link it's like having more RAM in the client machine.
What masterful release are you talking about? Windows 7 isn't even out yet. If you're going to prepare trolls in advance at least make sure you don't post them too early.
I confirm that Load Cycle Count on *all* of my laptops and even some old hard disk drives will go from changing dozens of times per hour to once per power up, if hdparm is given -B254. The audible click is, well, audible, so it's a mechanical process.
I think it's supposed to be Load cycle, not Power cycle, at least that's what I've seen to check for.
Most desktop drives don't have the problem to begin with, it's just laptop drives that run in suicide mode by default.
One of my very old laptop disks ran down to malfunction over years of running Slackware, Gentoo, FreeBSD, NetBSD, whatever you can name, and they all contributed to the problem whenever I did not disable the disk's default power management.
Debian Lenny and Ubuntu Intrepid both force sane power management out of the box, even on a text-only install. I consider the problem solved.
If Microsoft had been even remotely competent they would have included at least two checksums for each file, so that once you downloaded them from an untrusted source, the file becomes trusted by verifying all of its checksums. Just one checksum may be cracked but two in different algorithms are much less likely.
30 MB/s is your idea of fast file copying? On Linux I get 20 just off old external hard drives, 40-50 with eSATA on 2.5"s, and 70+ on any modern 3.5". What the hell is Vista doing that makes file copies so slow? Read block, write block. Where is all that overhead coming from such that you're getting less than 50% of my throughput just because you booted Vista?
He means it runs on a set of computer types which has a higher cardinality than Vista's. Linux natively runs on architectures that no Windows has never even been emulated on, let alone run natively. Now embedded + desktop + server hardware is almost all coming together as x86, so Windows is no longer at such a disadvantage, but what he said about the current number of types of machines Linux running on is correct.
Only if *everyone* alive is a member of the Master Race will life become simpler.
You know I've even heard there are entire operating systems other than Windows? That there are CPU architectures other than x86? If you're the kind of developer who refuses to support every operating system except Win64, supporting Win32 would be only slightly less of a crime.
Windows can hardly manage 10,000 system calls per second. You'd be very lucky to even get 1000 game logic updates per second on a *realtime* system, let alone a userland thread with syscall based locking, which again is all Windows has. 100 is much more reasonable.
Nope - thanks for the update. SSD will only defeat software file shredders if run through an FTL (which most are, but we should be moving away from this). However if your flash-optimised file system like ubifs does rotating writes then once again a file shredder is useless and will just waste erase blocks.
Ideally you'd just use block level encryption before writing the data in the first place. For years now it has been very easy to set up a volume manager (lvm, gvinum, ...) over an encrypted volume (device-mapper, geli) over software raid (md, gmirror) on server-class operating systems like Linux and FreeBSD. You get volume management, RAID and encryption, at the cost of entering a password and some ever-shrinking performance penalty.
I know you're trolling and probably high as a kite being flown by another kite, but just in case anyone takes you seriously, let it be known that file shredding is not a kernel's job, and using a non-journalled filesystem (or a journalled filesystem set to not journal data blocks) will allow file shredders to work just fine.
However, a pass of zeroes is not enough as some magnetic domains will remain in their old state and allow partial data recovery.
ZFS RAID1 (and RAID-Z and RAID-Z2) can heal over corrupted blocks from the redundant copy. This is not possible with hardware RAID since it doesn't know which copy is valid.
Try to run a webserver with caching built in. Chances are good 295 of those 300 files are going to be reloaded per page and can be stored in memory indefinitely. Last I heard, memory is still faster than SSD.
Screw VMware, DOS apps run in dosbox. That's what it's for.
Windows 7 has new CPU scheduling, a revised WDDM, a revised DWM, I/O and kernel level locks removed, a new event based Service model (reducing RAM footprint), new low latency push/pull sound processing, and then starts adding end user features and upper level OS integration of features.
That sounds like what gets changed every 3-6 months in a Linux distribution like Ubuntu or Fedora. Are you suggesting that even after 2 years of full time work Microsoft can only make such small incremental improvements to Vista?
Hell, even the short changelog of the Linux kernel itself is more impressive once every ~3 months. What is Microsoft wasting so much time on?
Am I seriously the only person who suspects that i7 is short for i786? We've had i686 for a very long time.
I've been a FreeBSD and Linux user for several years. I must have missed the RFC for evil detection over SSH. Link?
What poor algorithm? Hash collisions aside, a password is a password. Only things like retry limits, retry delays, automatic blacklisting, etc. will make any difference, and as we've agreed, these are matters of configuration which must be identical between systems for any meaningful comparison.
Regardless of what kernel is running, a password auth's security hinges on the password. Yes, for Windows it's probably even easier to probe SMB or IIS, but the password auth will be just as good or bad as OpenBSD if configured the same.
So, Mr Formal Education In Operating Systems, will OpenBSD refuse a valid username and password combination because the person logging in has a hidden evil deep in their hearts, unlike Windows which has blind faith in all valid passwords?
You're very confused. It's true that, if configured to accept username and password authentication, any system will treat a valid username and password as sufficient. That's why most professional administrators use public key authentication with good private key protection policies. But given an equal configuration of username and password, OpenBSD will be just as trusting as Windows.