The original point of the 100,000 KLOC measure was a reference to the oft-speculated "bugs per KLOC" measure. The idea is that complexity is well correlated to lines of code.
What if with maybe, five equations input into Mathworks generates 2500 lines of code for a few simple algorithms but, most of the 2500 lines are checks. And the 2500 lines end up compiling to say, 10000 instructions.
Which measure do you use to determine the number of lines of code? In this case, because of the heavily abstracted definition of "coding", I'd say that no valid measure exists. Certainly neither the 2500 that are entirely machine generated, nor the 8000 instructions.
There, with that out of the way. Actually, it's probably going to take until they can resurrect their last COBOL programmer or find someone who they can train on a thirty year old system in less than a year.
If you can't manage two nines on a basic windows server, you're doing it wrong. If your service depends on a single server, you're still doing it wrong.
Lastly, is a performance reliability rating the same thing as uptime? I doubt it. If their server is down eight hours a day, they'd swap it immediately.
Higher resolution displays just often tend to be better quality. They're more likely to be used by consumers for watching movies and such and so they have a target to shoot for there. Not that you can't still buy low res displays, but they're almost always disappointing in comparison to bigger, brighter, higher resolution ones.
Sorry but I still don't buy it. With Windows, backward compatibility is heavily stressed and developers are encouraged to write for their audience. Microsoft still says, "If you're targetting legacy, we're still keeping Winforms, MFC, and native code APIs etc, up to date. But if you want to target anything XP or newer, we're really quite big fans of WPF or Silverlight on.NET."
Your comments don't make sense in light of the huge emphasis on backwards compatibility. DX11 games typically run on Windows XP just fine. Maybe they don't have DX11, maybe they fall back to the supported renderer, but you didn't lose anything there.
The problem is that instead of a linear chain of products with a huge emphasis on backwards compatibility, Linux is a a complex, interwoven tree where support for different architectures, features, and a million checkboxes on whether a certain package may or may not be supported. There's no comparison to Windows. That's the problem, there's already a fracturing market for Android because it appears they didn't put their foot down and demand minimum feature support to use the Android name. As a result, the developers are suffering, and thus the platform suffers.
DX11 supports backward compatibility, so new games typically fall back on the previous features. And there's only one DX11 standard that everyone either totally meets or doesn't get to advertise they support it. With Android, there's no single standard. IMO, this is a huge mistake.
Google should have let the OS be free, but said to the vendors, look, if you're going to advertise that you're selling Android, you need to meet some basic requirements to avoid compatibility issues. For example, to advertise that you're using Android 3.0 you need to support: multi-touch, if using an on-screen keyboard exclusively the resolution needs to be at least X by Y, you must implement the full Android Java API, the Android Native API with working compiler that passes some basic regression tests, if using a GPS, camera or other sensors, you must use the published API and accurately tell the application the resolution of those sensors.
Etc. If they aren't doing this, I feel that they didn't see the forest for the trees. The only reason I can think that they wouldn't do that is to encourage early support and adoption. But they need to get on the standardization bandwagon soon before their platform ceases to be.
Real security is complex. You want application X to do A, B, and C. Application Y can only do A and C, application Z can do A except when X is doing C, or whatever.
SELinux affords you a lot of options, more options than I could correctly configure. On the other hand, the ability for security experts to create predesigned secure profiles will reduce the apparent complexity.
1TB of storage at $150 is not including any redundancy.
If quoted less than 20 cents a GB (using 2010 prices) then it's almost certain there is no redundancy, let alone a dedicated storage infrastructure to provide failover if the server dies.
First, let me say that SELinux is an enormously complex system that has the potential to provide huge security benefits for administrators, and that it is the bar by which other OS security infrastructure should be measured against.
With that out of the way, you're comparing apples to orange-seeds here. UAC is merely a component of the overall security model, and should most directly be compared to gksudo, sudo and su and other methods of user-initiated rights elevation. Additionally, the Windows security model does support some really fine-grained stuff now with mandatory access controls, support for signing trusted executables and all sorts of other complexity that the IT administrator can get into if they want. It's not as easy as SELinux yet, I don't think, but it's not far away either. It's not vetted by the NSA either, so I suppose that'd be a minus.
If you want to restrict the average user but the CEO wants to look at naughty sites, you're going to have to use a proxy and force one or the other to go through it, and then use a transparent proxy for the other.
Either that or you've got some really nice network hardware that can handle it, in which case hats off to you. But will that work if the CEO logs in on the plebian's terminal?
IE8, I can take it or leave it. And though I've never personally deployed Sharepoint, though it does look interesting and useful, it does come with all the tools you need to get the data back out. It's just a SQL Server database. I mean, no matter who you go with for document management you're going to end up putting data in a system and then having to change it to put it in some other system.
You almost puked that GE took the lowest common denominator OS to program for, likely paid some outsourced tech firm to write the bare minimum code to write the driver, and it has bugs that are so bad that they cause blue screens?
Yeah, I guess that'd make me feel queasy in a doctor's office too.
Well look at it this way, at least they didn't use underpaid, underqualified programmers to make Linux have kernel panics. That'd just be horrible.
What I've found is that the communities are exactly as helpful as your question's accuracy. So educated people asking pointed, informed questions will find the community delightful and helpful. Newbies to Linux will find the complete opposite. Most communities will cater to the former just fine, far fewer for the latter.
Just thought I'd add some of my own broad generalizations.
You're missing the point, unverified code is insecure code. Whether that's Windows or Linux.
For example, can you prove without a doubt that there exists no kernel or kernel module flaw that could result in running arbitrary code from an innocuous file on the filesystem at boot time? No, not even close. There's simply no way you could make that claim.
While it's improbable that such flaws exist in the Linux kernel, it's entirely possible. It's possible that there exists a flaw that allows hijacking a running kernel over the network and so the rootkit could exist purely in memory, relying on the resilience of the network to maintain its presence.
My point was simply that claiming Windows is difficult to secure are ignoring that the the competition is only secure because it's less in the bullseye. Linux isn't any more provably secure than Windows, a statement that's as true as it is regrettable. It'd be -fantastic- if Linux were written to a spec and machine verified. It'd also be an absurdly difficult enterprise that could cost hundreds of millions of dollars and would stall the kernel development for so long that it'd become obsolete.
You can't secure any unverified code without unplugging it. And verifying, truly verifying code is expensive and laborious and will likely never be done for something as huge as Windows or a Linux distro.
Unfortunately, the cost-benefit analysis of verifying code against a spec and proving the security of it shows that it's not worth it in the vast majority of situations.
Game X didn't have DRM, so it's fairly safe to assume the same for Game X+1 even though they're being developed by different companies, and X+1 is being developed by a company owned by EA, whose DRM is notorious in the gaming world.
If you use truecrypt, use full disk encryption or set the policy option to zero out the page file on shutdown, or numerous other things you could do.
Without a pagefile though, there will be some random quirks that you'll have when using Windows. I don't know how similar it'd be to running linux without a swap partition.
Slashdot Mirror
Can I come by and just play with all the tools you have some day?
The original point of the 100,000 KLOC measure was a reference to the oft-speculated "bugs per KLOC" measure. The idea is that complexity is well correlated to lines of code.
What if with maybe, five equations input into Mathworks generates 2500 lines of code for a few simple algorithms but, most of the 2500 lines are checks. And the 2500 lines end up compiling to say, 10000 instructions.
Which measure do you use to determine the number of lines of code? In this case, because of the heavily abstracted definition of "coding", I'd say that no valid measure exists. Certainly neither the 2500 that are entirely machine generated, nor the 8000 instructions.
<fallacy>And gosh darnit, the best way to remedy the ambiguity would be to refuse to confront it.</fallacy>
I'll pre-whoosh myself here:
*whoosh*
There, with that out of the way. Actually, it's probably going to take until they can resurrect their last COBOL programmer or find someone who they can train on a thirty year old system in less than a year.
If you can't manage two nines on a basic windows server, you're doing it wrong. If your service depends on a single server, you're still doing it wrong.
Lastly, is a performance reliability rating the same thing as uptime? I doubt it. If their server is down eight hours a day, they'd swap it immediately.
Higher resolution displays just often tend to be better quality. They're more likely to be used by consumers for watching movies and such and so they have a target to shoot for there. Not that you can't still buy low res displays, but they're almost always disappointing in comparison to bigger, brighter, higher resolution ones.
Sorry but I still don't buy it. With Windows, backward compatibility is heavily stressed and developers are encouraged to write for their audience. Microsoft still says, "If you're targetting legacy, we're still keeping Winforms, MFC, and native code APIs etc, up to date. But if you want to target anything XP or newer, we're really quite big fans of WPF or Silverlight on .NET."
Your comments don't make sense in light of the huge emphasis on backwards compatibility. DX11 games typically run on Windows XP just fine. Maybe they don't have DX11, maybe they fall back to the supported renderer, but you didn't lose anything there.
The problem is that instead of a linear chain of products with a huge emphasis on backwards compatibility, Linux is a a complex, interwoven tree where support for different architectures, features, and a million checkboxes on whether a certain package may or may not be supported. There's no comparison to Windows. That's the problem, there's already a fracturing market for Android because it appears they didn't put their foot down and demand minimum feature support to use the Android name. As a result, the developers are suffering, and thus the platform suffers.
There are a large number of unsupported Windows versions?
The analogy here to Windows is fail all around and should probably be avoided.
DX11 supports backward compatibility, so new games typically fall back on the previous features. And there's only one DX11 standard that everyone either totally meets or doesn't get to advertise they support it. With Android, there's no single standard. IMO, this is a huge mistake.
Google should have let the OS be free, but said to the vendors, look, if you're going to advertise that you're selling Android, you need to meet some basic requirements to avoid compatibility issues. For example, to advertise that you're using Android 3.0 you need to support: multi-touch, if using an on-screen keyboard exclusively the resolution needs to be at least X by Y, you must implement the full Android Java API, the Android Native API with working compiler that passes some basic regression tests, if using a GPS, camera or other sensors, you must use the published API and accurately tell the application the resolution of those sensors.
Etc. If they aren't doing this, I feel that they didn't see the forest for the trees. The only reason I can think that they wouldn't do that is to encourage early support and adoption. But they need to get on the standardization bandwagon soon before their platform ceases to be.
You can't prove god didn't do it so why don't we throw his hat into the ring of "possible causes for global warming."
Real security is complex. You want application X to do A, B, and C. Application Y can only do A and C, application Z can do A except when X is doing C, or whatever.
SELinux affords you a lot of options, more options than I could correctly configure. On the other hand, the ability for security experts to create predesigned secure profiles will reduce the apparent complexity.
I aim to please.
Thanks for that.
1TB of storage at $150 is not including any redundancy.
If quoted less than 20 cents a GB (using 2010 prices) then it's almost certain there is no redundancy, let alone a dedicated storage infrastructure to provide failover if the server dies.
First, let me say that SELinux is an enormously complex system that has the potential to provide huge security benefits for administrators, and that it is the bar by which other OS security infrastructure should be measured against.
With that out of the way, you're comparing apples to orange-seeds here. UAC is merely a component of the overall security model, and should most directly be compared to gksudo, sudo and su and other methods of user-initiated rights elevation. Additionally, the Windows security model does support some really fine-grained stuff now with mandatory access controls, support for signing trusted executables and all sorts of other complexity that the IT administrator can get into if they want. It's not as easy as SELinux yet, I don't think, but it's not far away either. It's not vetted by the NSA either, so I suppose that'd be a minus.
If you want to restrict the average user but the CEO wants to look at naughty sites, you're going to have to use a proxy and force one or the other to go through it, and then use a transparent proxy for the other.
Either that or you've got some really nice network hardware that can handle it, in which case hats off to you. But will that work if the CEO logs in on the plebian's terminal?
IE8, I can take it or leave it. And though I've never personally deployed Sharepoint, though it does look interesting and useful, it does come with all the tools you need to get the data back out. It's just a SQL Server database. I mean, no matter who you go with for document management you're going to end up putting data in a system and then having to change it to put it in some other system.
You almost puked that GE took the lowest common denominator OS to program for, likely paid some outsourced tech firm to write the bare minimum code to write the driver, and it has bugs that are so bad that they cause blue screens?
Yeah, I guess that'd make me feel queasy in a doctor's office too.
Well look at it this way, at least they didn't use underpaid, underqualified programmers to make Linux have kernel panics. That'd just be horrible.
Everyone knows there's a shadow-bus on the motherboard that only open source operating systems have access to.
What I've found is that the communities are exactly as helpful as your question's accuracy. So educated people asking pointed, informed questions will find the community delightful and helpful. Newbies to Linux will find the complete opposite. Most communities will cater to the former just fine, far fewer for the latter.
Just thought I'd add some of my own broad generalizations.
You're missing the point, unverified code is insecure code. Whether that's Windows or Linux.
For example, can you prove without a doubt that there exists no kernel or kernel module flaw that could result in running arbitrary code from an innocuous file on the filesystem at boot time? No, not even close. There's simply no way you could make that claim.
While it's improbable that such flaws exist in the Linux kernel, it's entirely possible. It's possible that there exists a flaw that allows hijacking a running kernel over the network and so the rootkit could exist purely in memory, relying on the resilience of the network to maintain its presence.
My point was simply that claiming Windows is difficult to secure are ignoring that the the competition is only secure because it's less in the bullseye. Linux isn't any more provably secure than Windows, a statement that's as true as it is regrettable. It'd be -fantastic- if Linux were written to a spec and machine verified. It'd also be an absurdly difficult enterprise that could cost hundreds of millions of dollars and would stall the kernel development for so long that it'd become obsolete.
You can't secure any unverified code without unplugging it. And verifying, truly verifying code is expensive and laborious and will likely never be done for something as huge as Windows or a Linux distro.
Unfortunately, the cost-benefit analysis of verifying code against a spec and proving the security of it shows that it's not worth it in the vast majority of situations.
Game X didn't have DRM, so it's fairly safe to assume the same for Game X+1 even though they're being developed by different companies, and X+1 is being developed by a company owned by EA, whose DRM is notorious in the gaming world.
If you use truecrypt, use full disk encryption or set the policy option to zero out the page file on shutdown, or numerous other things you could do.
Without a pagefile though, there will be some random quirks that you'll have when using Windows. I don't know how similar it'd be to running linux without a swap partition.
Well sure but it's a lot easier to say 4 trillion Celsius than "Four trillion two hundred seventy three point one five degrees Kelvin."