Longhorn never was a managed code approach, which is still a lofty research goal (and may still be brewing behind the scenes at Microsoft Research through Midori, Barrelfish, and Singularity.)
Longhorn did however try to incorporate a bunch of other research projects right from the get-go, most of which were spun off into individual projects or into existing products. Avalon was supposed to replace winforms, WinFS was supposed to replace NTFS, Palladium was supposed to be incorporated, etc. The development team was spinning their wheels trying to adapt to the latest demand to use the latest research products instead of developing along a stable path. By the time the "reset" came Microsoft had already missed their 3 year OS schedule and it was going to take another 3 to turn Longhorn into a releasable product. While many user applications (Explorer, for example) were partially rewritten in.NET, they represented only a small portion of the total code.
Windows 7 by comparison was released with teams focusing on milestones internally and not releasing or demonstrating any not-done-yet feature. Essentially each feature that a team proposed was a patchset on the Windows build and they would test it but if it did not make the cut, they didn't apply the patch to the milestone build. The Engineering Windows 7 blog goes into great detail about the development process that was vastly improved over Windows Vista's.
But in the case of HTML5, the interesting stuff is all being done by the client. The server is a dumb file server. There is no way for the server to know the difference between a user downloading the video file referenced in the tag and a user streaming, watching it as it downloads.
That would require the server to insert those slices into the feeds in realtime. But right now, there's no difference in HTML5 between a client downloading (as in, saving for later) a video and streaming a video. In both cases, the server is a dumb file server, and the client is downloading the video referenced. In the case of the tag, the browser might be clever and download at a lower bandwidth than its maximum because it doesn't need to.
Variable bit rate encoded video does not allow a downloading client to skip chunks because they can't keep up, because those chunks encode whole frames and, in the case of H.264, frame data contains references to the previous frame to perform operations on them. So the result is that the client still has to download every frame, and the server is simply serving up a dumb file.
What you want is for the server to have say, ten different versions of the same video, encoded at different bit-rates, and for the client to be able to switch from one to another smoothly. Just because it's variable bit rate, does not mean the client can choose to not download some bits. They have to download all of them, and the average bit rate might be greater than their bandwidth. So they need to be able to switch streams. Silverlight does this, Flash allows this, HTML5 does not. See the problem?
You don't understand. By variable bitrate, they mean changing the bitrate on a per-viewer basis. So, if someone has a particularly bad connection, it gives them a lower quality picture so that they can keep up. And if they're connection improves (they turn off their torrents, for example) then the bitrate they are being provided would improve.
As far as I know, the object in HTML5 does not allow swapping out the referenced video while it's playing with another one encoded at a different bitrate. Silverlight does this for you with its streaming engine, with Flash it's at least possible to synchronize all the components, but it's rarely done. (You need to synchronize audio and video to a high degree of precision to avoid the user noticing.)
This is a valid complaint, and actually one of Microsoft's major selling points on Silverlight, and it's why Netflix adopted it for their online viewer. The variable bitrate per viewer playback that adjusts itself according to your connection is extremely important to providing at least a basic experience. Netflix's implementation is a little bad (it does pause the video if your connection quality goes down, but there are other Silverlight players that do it seamlessly.)
Enterprise support is only available for Enterprise support customers, but yes, it's very excellent. They usually get me right to someone who knows exactly what they're doing, and they don't BS me with tiers of support calls.
Well that's all pretty obvious no? The only thing truly embarrassing about multicore is how poorly recognized embarrassingly parallel problems are.
Microsoft supports lightweight threads (fibers), OpenCL runs on Windows, etc. The Go programming language, which runs lightweight threads in software, runs great on Windows. So, yeah, there are options for Windows. Saying that the only options are MacOS, *Nix and *BSD is pure FUD.
Let me put it this way. If you wanted to write a cross-platform C/C++ application, and you started writing it for Linux, would you place critical dependencies on the Linux kernel and the specific userland that's common on Linux distros, or would you abstract those away to minimize the cost of switching OS?
I think the answer is pretty obvious, and the same applies to.NET.
I liked the trainwreck of a satire you wrote. It was really good until you started saying thing that are true a little less than halfway through your second paragraph.:)
ASP.NET and ADO.NET are largely in the "open" part, with very few components in the "not-open, Microsoft internal" part. Mono have implemented most of ASP.NET and it's possible to run ASP.NET code using some of their more recent projects on Apache.
Winforms is so specific (and in many ways, trivial to implement as it's a layer over Win32) that no one would bother implementing it. Most anything interesting that you want to do with Winforms you have to do with p/invoke already. (Want to extend the Aero glass frame into your window? P/invoke!)
I'd say most of the libraries that would matter for open source OS implementation are open. Even WPF has an open specification (though I'm unsure if it's covered by the patent promise) but there's no desire to implement it because it'd require a huge amount of work on the Linux kernel or the creation of a support layer. WPF uses a lot of the basic Windows graphics libraries (DirectX stuff like DirectWrite) for acceleration and other stuff that would all have to be re-implemented. Why bother when it's so much easier to support QT?
The.NET source code is not redistributable or licensed freely, and they've said as much. The source code is there for debugging purposes only. It'd be like if Apple let you step through their Core libraries when debugging in X-Code. Apple wouldn't be saying, "Go on, take this code and write your own set of libraries to totally supplant ours!" (This would piss Jobs off far more than porn on the iPhone.)
There's free and open source alternatives to Visual Studio for coding.NET, and for native code there are myriad tools that run on Windows. Probably the best maintained is MinGW.
If you don't like the Visual Studio toolchain, then you don't have to pay for it. And the cheapest Visual Studio that does the in-IDE debugging of.NET framework code is about $800, but I hear you on the price. It's a pity they axed Standard edition but I understand their motives.
To expand on what he said, Visual Studio supports downloading and using the.NET source code and stepping through it with the debugger. This lets accomplished users determine where a problem in the code lies if it involves (often-times) complex API calls.
This would be akin to, I suppose, using GDB with your kernel + library sources plugged in as well.
Yes but it consumes more power and heat than they'd like. Binning is also a bigger deal than you think with CPUs. My CPU can be over-clocked significantly, because I got a lucky unit, but not nearly as much as what some people get. My CPU isn't stable at the memory speeds most over-clockers see online either. So in some ways, I got a good CPU, in some, it's meh.
On the other hand, there's no way I'd sell a company my CPU & motherboard at the speed I've boosted it up to. Not a chance. It's not 100% stable, there are infrequent glitches, etc. I improved my cooling, decreased my over-clock, and I've still had it not wake up from s3 sleep and done a couple other odd things.
So no, super turbo boost is not what you think it is. Is it a marketing ploy? Everything is a marketing ploy, but it's also a useful feature. Especially on laptops, where all but one core of the CPU can completely shut down and the remaining one can nearly double its clock speed.
There are cases where state's laws modify Federal laws or regulations, usually by making them more strict. There are also completely novel laws, which as I said, could be maintained in a separate version controlled text.
How about we version control the legal code, consider amendments to be patches, new laws to be insertions into the relevant sections, and deprecated text removed in a deletion patch?
State governments could then add their own changeset to the upstream (Federal) laws where they can and also maintain their own single cohesive text as a version controlled document.
Unfortunately such a thing is probably decades if not centuries away.
Having worked with a county sheriff's office and their 911 system, I can tell you that it is possible to regulate the Windows system clock quite well, as they require it. It just isn't "high frequency trading" quality.
But I doubt you'd use the Linux kernel time for high frequency trading either. You'd probably opt for something specifically designed for just that task, and designed to do it particularly well.
DD, Dump and Tar are great if all you want is crash consistency, which is not what Windows does. When Windows creates a binary snapshot the snapshot is of an essentially offline system. All critical data will be in a known good state. Any applications that run can participate in the snapshot process and additionally assert that their data is in a known good state. If you were to do a dd of a running MySQL with a database measuring in the tens of gigabytes, you would lose data and possibly corrupt your database. Even if you use a snapshot through LVM, you're essentially in a crash consistent state, and restoring that backup will require MySQL to rebuild everything. PostgreSQL has better logging and will simply roll back or replay transactions as needed.
LVM snapshots are a lot like snapshots on commodity or I guess low tier SANs. They're completely unaware of what they're snapshotting, so they have no choice but to rather dumbly create a snapshot volume where every single byte, sector or block that is altered has to be stored, and they aren't capable of intelligently rearranging those units (based on whatever its minimum is) to match filesystem access patterns.
Basically, they're an enormous performance hit, and having more than one snapshot concurrently is going to have your DBA screaming at you because your database throughput can now be measured with a notepad, ballpoint pen and your watch. If you want to experience what that's like, have LVM take six or more snapshots and keep them around for a while. On the other hand, an intelligent filesystem can snapshot and keep the changed blocks close to the original blocks, and minimize fragmentation or additional access indirections that would slow down the system.
I really hope you don't think the options you listed are really the best Linux has to offer. Because, first of all, they're not. There are some clever people who have smarter ideas about backing up (and dealing with MySQL intelligently.) And there are some significant benefits to improving the base filesystem. LVM snapshots are the wrong way to go. I'd only ever use those temporarily for a backup, but still, NTFS, ZFS, BTRFS snapshots have minimal overhead compared to those ugly things.
The fact is, advanced tools are just that, advanced. Windows comes with bare metal tools, and the ability to properly configure a daily, weekly, etc, backup on external disk. And there are more advanced features for the adventurous. I guarantee you I won't lose data if my Windows box dies. I have daily backups, a RAID10 internal with a hot spare, blah blah blah. But I'm not a typical user.
And neither are you. We both know how to use our OS to protect our data, even if it involved what appears to be wizardry to the average user. I really wish backup were easier. Windows 7 actually informs the user regularly that they don't have a backup, and will continue to warn them if a backup ever fails. That's great progress, but it's maybe not yet good enough. Let me know when a popular Linux distro supports bare metal backup and a snapshotting filesystem with the ability to "go back in time" to a good state, I look forward to that day. Until then, you have your wizardry, I have my slightly-less-magical-looking GUI that manages most of it for me built in. *shrugs*
IMO, I'd like to get to the point where OSes, Windows, Mac, Linux, really, seriously warn the user the moment their data isn't safe. It's one thing for Windows 7 to pop up a notification balloon, or for OS X to complain that Time Machine isn't set up, but I feel like there should be more than that. And on Linux, I don't think there's anything comparable at the moment.
The restore points use something similar to a snapshotting filesystem. So the restore point causes copy-on-write to occur on all data on the disk after it's created. So naturally, restore points can become quite large if you have any sizable amount of data churn on your disk. (I do, and my restore points are enormous as a result.)
However, I have set my disk to allow not only 30% of its total storage for restore points, and I also have a daily backup set up. The daily backup is greatly aided by the snapshotting, and so it runs in only a few minutes to an hour (if there's been a lot of changes) and the backup itself is snapshotting using the same features. So my oldest restore point is 8/30/2009 at 7:00PM, and that's when I bought the hard drive I'm currently using for backups.
There are pluses and minuses. But a lot of problems in any OS can be traced back to people doing the same thing that's the root of all evil in programming: premature optimization. They don't understand the implications of what they're doing, and reduce the allowed size of restore points, or manually create dozens (even though it's automatically done every time a program is installed or an update is applied.) Or they just plain don't know what they're doing but fire up the registry editor anyway. These things, or things like them, are bad ideas in any OS.
Didn't say they had to release it on day one. But if they say, "Alright, we're closing up. Here's the source code for the servers" the day service ends, that'd be fine by me.
Slashdot Mirror
Longhorn never was a managed code approach, which is still a lofty research goal (and may still be brewing behind the scenes at Microsoft Research through Midori, Barrelfish, and Singularity.)
Longhorn did however try to incorporate a bunch of other research projects right from the get-go, most of which were spun off into individual projects or into existing products. Avalon was supposed to replace winforms, WinFS was supposed to replace NTFS, Palladium was supposed to be incorporated, etc. The development team was spinning their wheels trying to adapt to the latest demand to use the latest research products instead of developing along a stable path. By the time the "reset" came Microsoft had already missed their 3 year OS schedule and it was going to take another 3 to turn Longhorn into a releasable product. While many user applications (Explorer, for example) were partially rewritten in .NET, they represented only a small portion of the total code.
Windows 7 by comparison was released with teams focusing on milestones internally and not releasing or demonstrating any not-done-yet feature. Essentially each feature that a team proposed was a patchset on the Windows build and they would test it but if it did not make the cut, they didn't apply the patch to the milestone build. The Engineering Windows 7 blog goes into great detail about the development process that was vastly improved over Windows Vista's.
But in the case of HTML5, the interesting stuff is all being done by the client. The server is a dumb file server. There is no way for the server to know the difference between a user downloading the video file referenced in the tag and a user streaming, watching it as it downloads.
That would require the server to insert those slices into the feeds in realtime. But right now, there's no difference in HTML5 between a client downloading (as in, saving for later) a video and streaming a video. In both cases, the server is a dumb file server, and the client is downloading the video referenced. In the case of the tag, the browser might be clever and download at a lower bandwidth than its maximum because it doesn't need to.
Variable bit rate encoded video does not allow a downloading client to skip chunks because they can't keep up, because those chunks encode whole frames and, in the case of H.264, frame data contains references to the previous frame to perform operations on them. So the result is that the client still has to download every frame, and the server is simply serving up a dumb file.
What you want is for the server to have say, ten different versions of the same video, encoded at different bit-rates, and for the client to be able to switch from one to another smoothly. Just because it's variable bit rate, does not mean the client can choose to not download some bits. They have to download all of them, and the average bit rate might be greater than their bandwidth. So they need to be able to switch streams. Silverlight does this, Flash allows this, HTML5 does not. See the problem?
You don't understand. By variable bitrate, they mean changing the bitrate on a per-viewer basis. So, if someone has a particularly bad connection, it gives them a lower quality picture so that they can keep up. And if they're connection improves (they turn off their torrents, for example) then the bitrate they are being provided would improve.
As far as I know, the object in HTML5 does not allow swapping out the referenced video while it's playing with another one encoded at a different bitrate. Silverlight does this for you with its streaming engine, with Flash it's at least possible to synchronize all the components, but it's rarely done. (You need to synchronize audio and video to a high degree of precision to avoid the user noticing.)
This is a valid complaint, and actually one of Microsoft's major selling points on Silverlight, and it's why Netflix adopted it for their online viewer. The variable bitrate per viewer playback that adjusts itself according to your connection is extremely important to providing at least a basic experience. Netflix's implementation is a little bad (it does pause the video if your connection quality goes down, but there are other Silverlight players that do it seamlessly.)
Mod +1 "the support tech is remotely connected and figuring out the problem while my heart races and I worry about my job."
Enterprise support is only available for Enterprise support customers, but yes, it's very excellent. They usually get me right to someone who knows exactly what they're doing, and they don't BS me with tiers of support calls.
Well that's all pretty obvious no? The only thing truly embarrassing about multicore is how poorly recognized embarrassingly parallel problems are.
Microsoft supports lightweight threads (fibers), OpenCL runs on Windows, etc. The Go programming language, which runs lightweight threads in software, runs great on Windows. So, yeah, there are options for Windows. Saying that the only options are MacOS, *Nix and *BSD is pure FUD.
Let me put it this way. If you wanted to write a cross-platform C/C++ application, and you started writing it for Linux, would you place critical dependencies on the Linux kernel and the specific userland that's common on Linux distros, or would you abstract those away to minimize the cost of switching OS?
I think the answer is pretty obvious, and the same applies to .NET.
I liked the trainwreck of a satire you wrote. It was really good until you started saying thing that are true a little less than halfway through your second paragraph. :)
ASP.NET and ADO.NET are largely in the "open" part, with very few components in the "not-open, Microsoft internal" part. Mono have implemented most of ASP.NET and it's possible to run ASP.NET code using some of their more recent projects on Apache.
Winforms is so specific (and in many ways, trivial to implement as it's a layer over Win32) that no one would bother implementing it. Most anything interesting that you want to do with Winforms you have to do with p/invoke already. (Want to extend the Aero glass frame into your window? P/invoke!)
I'd say most of the libraries that would matter for open source OS implementation are open. Even WPF has an open specification (though I'm unsure if it's covered by the patent promise) but there's no desire to implement it because it'd require a huge amount of work on the Linux kernel or the creation of a support layer. WPF uses a lot of the basic Windows graphics libraries (DirectX stuff like DirectWrite) for acceleration and other stuff that would all have to be re-implemented. Why bother when it's so much easier to support QT?
The .NET source code is not redistributable or licensed freely, and they've said as much. The source code is there for debugging purposes only. It'd be like if Apple let you step through their Core libraries when debugging in X-Code. Apple wouldn't be saying, "Go on, take this code and write your own set of libraries to totally supplant ours!" (This would piss Jobs off far more than porn on the iPhone.)
There's free and open source alternatives to Visual Studio for coding .NET, and for native code there are myriad tools that run on Windows. Probably the best maintained is MinGW.
If you don't like the Visual Studio toolchain, then you don't have to pay for it. And the cheapest Visual Studio that does the in-IDE debugging of .NET framework code is about $800, but I hear you on the price. It's a pity they axed Standard edition but I understand their motives.
To expand on what he said, Visual Studio supports downloading and using the .NET source code and stepping through it with the debugger. This lets accomplished users determine where a problem in the code lies if it involves (often-times) complex API calls.
This would be akin to, I suppose, using GDB with your kernel + library sources plugged in as well.
Yes but it consumes more power and heat than they'd like. Binning is also a bigger deal than you think with CPUs. My CPU can be over-clocked significantly, because I got a lucky unit, but not nearly as much as what some people get. My CPU isn't stable at the memory speeds most over-clockers see online either. So in some ways, I got a good CPU, in some, it's meh.
On the other hand, there's no way I'd sell a company my CPU & motherboard at the speed I've boosted it up to. Not a chance. It's not 100% stable, there are infrequent glitches, etc. I improved my cooling, decreased my over-clock, and I've still had it not wake up from s3 sleep and done a couple other odd things.
So no, super turbo boost is not what you think it is. Is it a marketing ploy? Everything is a marketing ploy, but it's also a useful feature. Especially on laptops, where all but one core of the CPU can completely shut down and the remaining one can nearly double its clock speed.
He could adopt.
There are cases where state's laws modify Federal laws or regulations, usually by making them more strict. There are also completely novel laws, which as I said, could be maintained in a separate version controlled text.
How about we version control the legal code, consider amendments to be patches, new laws to be insertions into the relevant sections, and deprecated text removed in a deletion patch?
State governments could then add their own changeset to the upstream (Federal) laws where they can and also maintain their own single cohesive text as a version controlled document.
Unfortunately such a thing is probably decades if not centuries away.
Addendum: I thought I'd add that they use hardware GPS modules to receive the current time, as NTP is considered not reliable enough for them.
Having worked with a county sheriff's office and their 911 system, I can tell you that it is possible to regulate the Windows system clock quite well, as they require it. It just isn't "high frequency trading" quality.
But I doubt you'd use the Linux kernel time for high frequency trading either. You'd probably opt for something specifically designed for just that task, and designed to do it particularly well.
DD, Dump and Tar are great if all you want is crash consistency, which is not what Windows does. When Windows creates a binary snapshot the snapshot is of an essentially offline system. All critical data will be in a known good state. Any applications that run can participate in the snapshot process and additionally assert that their data is in a known good state. If you were to do a dd of a running MySQL with a database measuring in the tens of gigabytes, you would lose data and possibly corrupt your database. Even if you use a snapshot through LVM, you're essentially in a crash consistent state, and restoring that backup will require MySQL to rebuild everything. PostgreSQL has better logging and will simply roll back or replay transactions as needed.
LVM snapshots are a lot like snapshots on commodity or I guess low tier SANs. They're completely unaware of what they're snapshotting, so they have no choice but to rather dumbly create a snapshot volume where every single byte, sector or block that is altered has to be stored, and they aren't capable of intelligently rearranging those units (based on whatever its minimum is) to match filesystem access patterns.
Basically, they're an enormous performance hit, and having more than one snapshot concurrently is going to have your DBA screaming at you because your database throughput can now be measured with a notepad, ballpoint pen and your watch. If you want to experience what that's like, have LVM take six or more snapshots and keep them around for a while. On the other hand, an intelligent filesystem can snapshot and keep the changed blocks close to the original blocks, and minimize fragmentation or additional access indirections that would slow down the system.
I really hope you don't think the options you listed are really the best Linux has to offer. Because, first of all, they're not. There are some clever people who have smarter ideas about backing up (and dealing with MySQL intelligently.) And there are some significant benefits to improving the base filesystem. LVM snapshots are the wrong way to go. I'd only ever use those temporarily for a backup, but still, NTFS, ZFS, BTRFS snapshots have minimal overhead compared to those ugly things.
BTRFS isn't release quality yet. I definitely wouldn't run that without a strong backup procedure (which is what you have.)
The fact is, advanced tools are just that, advanced. Windows comes with bare metal tools, and the ability to properly configure a daily, weekly, etc, backup on external disk. And there are more advanced features for the adventurous. I guarantee you I won't lose data if my Windows box dies. I have daily backups, a RAID10 internal with a hot spare, blah blah blah. But I'm not a typical user.
And neither are you. We both know how to use our OS to protect our data, even if it involved what appears to be wizardry to the average user. I really wish backup were easier. Windows 7 actually informs the user regularly that they don't have a backup, and will continue to warn them if a backup ever fails. That's great progress, but it's maybe not yet good enough. Let me know when a popular Linux distro supports bare metal backup and a snapshotting filesystem with the ability to "go back in time" to a good state, I look forward to that day. Until then, you have your wizardry, I have my slightly-less-magical-looking GUI that manages most of it for me built in. *shrugs*
IMO, I'd like to get to the point where OSes, Windows, Mac, Linux, really, seriously warn the user the moment their data isn't safe. It's one thing for Windows 7 to pop up a notification balloon, or for OS X to complain that Time Machine isn't set up, but I feel like there should be more than that. And on Linux, I don't think there's anything comparable at the moment.
The restore points use something similar to a snapshotting filesystem. So the restore point causes copy-on-write to occur on all data on the disk after it's created. So naturally, restore points can become quite large if you have any sizable amount of data churn on your disk. (I do, and my restore points are enormous as a result.)
However, I have set my disk to allow not only 30% of its total storage for restore points, and I also have a daily backup set up. The daily backup is greatly aided by the snapshotting, and so it runs in only a few minutes to an hour (if there's been a lot of changes) and the backup itself is snapshotting using the same features. So my oldest restore point is 8/30/2009 at 7:00PM, and that's when I bought the hard drive I'm currently using for backups.
There are pluses and minuses. But a lot of problems in any OS can be traced back to people doing the same thing that's the root of all evil in programming: premature optimization. They don't understand the implications of what they're doing, and reduce the allowed size of restore points, or manually create dozens (even though it's automatically done every time a program is installed or an update is applied.) Or they just plain don't know what they're doing but fire up the registry editor anyway. These things, or things like them, are bad ideas in any OS.
Didn't say they had to release it on day one. But if they say, "Alright, we're closing up. Here's the source code for the servers" the day service ends, that'd be fine by me.