It would sell because its marketed as windows, and then customers would be disappointed because it didnt do the same things their desktop windows does. After a short while, it would earn itself a terrible reputation and people would avoid it, and the existing unwanted devices would show up on ebay very cheaply.
On it's own merit, windows rt offers nothing over android or ios, and at $200 the hardware would at best be the same spec as $200 android hardware if windows were given away for free. On the other hand, its unlikely to be free, so the hardware would be inferior to cover the cost and then you also have a much smaller pool of apps than android/ios devices have.
TFA is about Servers, not Desktops. Windows Servers tend to run specialized software already - Exchange, MS SqlServer, Oracle Database, etc. Yeah, there'd likely be some complaints regarding stupid admins; but the Server world is looking at using ARM-based systems especially in datacenters b/c they are cheaper to run and easier to scale out due to lower heat generation (which Intel has always been bad about).
This is just MS saying "we don't want to be left out" since Linux is currently able to take on all these ARM datacenter systems.
So if (when) they do release it, expect it to first hit the "Windows Server Data Center Edition" as an alternate version for use and "Windows Server Standard" so that devs have something to test with; or they may just keep the initial few releases to only supporting Microsoft Software (e.g. Exchange, SQL Server, etc); and don't be surprised if you see that configuration in Microsoft Azure before it goes out to anyone else either.
I agree, but I think they may be taking this into account. For one, having a detailed mapping of somewhat technically engaged populace gives them just a little more information in regards to determining what segments of the population to randomly select for enhanced census. I know they are supposed to try to hit everyone but with just the right emphasis on how hard to try in certain areas, the results can be skewed enough to matter.
Well, more accurately it can tell them when they've achieved a statistically significant portion of the region in order to deem the census valid without having to get 100% and know they have a statistically relevant/reliable number, making it easier to account for the people not being home, etc.
Of course, they'll also "know" your home under the assumption you didn't forget your cellular device(s) at "home" that day.
The problem is MS never had a small tutorial during windows installation or during the first boot showing users how to create a Standard User account and have an administrative account for elevating your rights for doing administrative stuff. But now, with windows 8 during the install, you can create any type account you like, but again, no tutorial.
The problem is one of history for Windows.
Windows was originally a place where every user was an Administrator. This encouraged developers to not pay attention to APIs used, so then applications came to be reliant on running only under users that were Administrators. Even Microsoft Office did that for a long time.
Then Microsoft split users up and now there was a special Administrator account and group. Except users wanted to continue using all the software they had from before that split. The solution? Make all users administrators. Developers kept designing software that required administrative access - even Microsoft Office.
Then came Windows Vista and UAC. Microsoft Office got fixed up; but many developers did not listen to years of warning. So then UAC started prompting the hell out of everyone. Windows 7 came along and most developers had fixed their software so UAC could be scaled back in its prompting some (really, that's the only difference between Win7 and Vista - the default threshold setting for UAC - in this matter).
Of course no where along the road did Microsoft make it easy to switch between users. Sure, there's "Run As..." but it's (a) not well known, (b) a PITA to use, and (c) doesn't solve every use case. UAC doesn't quite either. In neither case do either work like the priviledge escalation in Linux/Unix with "su" and "sudo" and their graphical equivalents. So everyone still must have the administrative access to do certain tasks.
And of course people are still trained that their user needs to be the Admin user for the system.
So there's still work to be done on Windows to bring a real "su"/"sudo" experience to Windows; but overall it's still very much a user issue since they're all trained to and expect that their Windows user will have admin rights whether they really need them or not.
The company is not interested in supporting the software. So if their software is in peril, it is entirely in their hands.
This situation doesn't sound unusual to me. The company originally developed it because it addressed a need/demand at the time. The developers involved took a personal interest in it. The original need has long gone, but the developers have kept it going as a personal project that the company indulges.
But once the original developers leave, the company has no reason to continue their involvement with it. The people using it are not their customers (or are insignificant enough to be customers of no value). They owe it nothing, and suffer no "embarrassment" from walking way from it.
That being said, I don't know why the poster hasn't come out and said what the software is. It may answer a number of questions.
It could be that they haven't announced anything yet, so it could cause "material harm" to the company or put the TFA's author in a bad position in the company to announce something prior to any official annoucement. There are numerous legal reasons to not necessarily name a project; however much the community here may want them to do so.
Why? You'd have the gov't spend money to overbuild or be able to scale a website for the one time every few years it gets overloaded? Seems like a waste of money to me. It does just fine 99.9999999% of the time.
The other issue was that all the news articles said things like, "X Million Hondas Recalled!" As a Honda Accord owner, I clicked on the article and looked, only to discover it was for rather old Accords (nothing newer than like 2003; ours is a 2012). Others probably went to safercar.gov instead, only to find it didn't apply. (That headline should have been in the favorite clickbait poll. "X Million Cars from 1998-2003 recalled!" would have been better, but...fewer clicks!)
Recall applied to many more than just Hondas, and many different model years even outside the 1998-2003 years you quoted. So sure, car's model may not have had an issue, but many others did.
Also, safecar.gov forwarded to the other site so that didn't really make a difference.
Finally, I would expect any organization that has a mission like that of the site in question to be prepared should a major issue like this happen, primarily because it could happen at any time and they are the central source of information. The fact that it is a government website only makes it more important to be able to scale.
Your argument is like saying that the IRS website need not scale b/c it works just fine for 350 days of the year; it's only less than 15 days of the year that it sees major amounts of traffic. Sorry - but that doesn't work and safety should have a higher burden of reliance than the IRS.
Then they were fools. The whole point of buying an established company is to buy the brand as well as the factories. Anyone can build a factory, usually for no more than it would cost to buy someone else out.
Except they weren't trying to buy the "brand". They were trying to buy the product to ensure that there was an actual product in the market with their failing OS on it; they were simply trying to buy market share; nothing more.
The fact that it's their name on it now won't change anything. It will still fail just as a badly as before (may be even worse).
And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited
Can you please cite the policy?
A quick glance through the Microsoft Security Bulletins reveals that most of them have not been actively exploited before being patched.
Of course you could argue that Microsoft is lying, but many security researchers do (privately) report vulnerabilities to Microsoft, and you really don't think some of them will publicize the bugs if they aren't fixed in, like, a year?
Or are you actually trying to say they don't fix them unless they have been reported, which is an entirely different thing?
Microsoft does not publicize all vulnerabilities reported to them; and not every reporter will publicize it either. So how many they actually know about is unknown. This is reported by most people that are writing about the issue, especially those comparing Microsoft's practices to Open Source's and comparing the numbers for the CVE reports between the groups.
I didn't say MS was better, I said the bash response was poor, and the poster I replied to couldn't possibly have had fixes in place within minutes as claimed.
I'm just pointing out that however poor the Bash devs response was, Microsoft's would have been worse.
Oh, and in your argument "up to 30 days" suddenly becomes "taken 30 days" - actually if bugs come in uniformly distributed in the 30 day cycle then average would be 15 days, or lower since sometimes they do go out-of-band.
Actually, my comment regarding "taken 30 days" for Microsoft is well founded in their historical turn-around for CVEs that they have acknowledged as being fixed. With a rare exception, they don't deliver any patches in under 30 days; and even 30 days is being gracious as it's usually more like 6 months so I'm already putting them on their own expedited schedule for such fixes.
Again, pointing out that however poor the Bash devs response was, Microsoft's at it best is worse.
Plus, the second (and third and fourth and so on) patches are only needed if the first (and second and third.,.) one is inadequate and not properly tested.
If the numerous people reviewing Bash, from multiple companies, and disciplines didn't find the issue with the first patch, then how would Microsoft with a far more limited set of people looking at the code be able to get the same kind of patch correct the first time and get all the corner cases figured out and fixed before releasing the first patch?
I'm not saying the Bash devs had 1 million eyes on this; but they certainly had a few hundred if not a thousand or so in total. Microsoft's equivalent group probably is no greater than 50 devs at best, likely smaller; and probably no where near the cross-discipinary skill set match either.
So if the Bash guys had to do a second patch (or even a third, etc) to fix it; chances are Microsoft would have had to have at least as many patches too.
Maybe MS are just as bad at that too, but the developers of Bash were certainly not good at it.
Agreed - kinda. The main point of the origin of this thread (article?) was that F/LOSS software could not deal as well as proprietary software; that somehow the proprietary vendors could do better with these kinds of bugs - both catching them and responding to them.
My point, is that based on its history - documented in numerous articles over the years - Microsoft is a prime example of showing that's not the case. That proprietary vendor's own policies and procedures prevent them from delivering anywhere near as good a turn around.
But here's the kicker - there is a similar exploit for cmd.exe. It's yet to be patched.;-)
here's an example: https://twitter.com/FioraAeter...
(And yes, I've seen it from other sources, just don't have those links right now.)
What should really happen is Mr. Rossi should patent his device, and then anyone who wants to can read the patent and build their own replica, if they wish to do so. (Of course to sell their replica they would need to license the design from Mr. Rossi, since it would be patented)
Perpetual Motion Machines (and Cold Fusion) require a working device to receive a patent. There have been so many hoaxes that the US PTO (at least) wants a physical machine they can inspect in order to issue the patent.
How did you fix them in minutes when it took several days for correct patches to come out, for entirely predictable reasons (laughable approach of trying to find and fix all bugs at once in a parser never designed to be secure, when the real issue is that it should never be being fed untrusted input) ?
To my mind, that is the biggest failure of open source / free software in this case
- 20+ yr old bug / insecure-feature in an obscure corner of a system never designed for today's threat environment - forgiveable
- responsible disclosure, working with maintainers under embargo - good
- publication along with a patch that was broken again within hours if not minutes - fail
- everyone and his dog then panic-issuing further patches for one parser vulnerability after another before eventually someone (actually more than one different approach) fixes it properly the way it should have been done in the first place - spectacular fail
And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited; when an unknown exploit is exploited they take up to 30 days to release, and that still may not have everything fixed.
So to put this in context, if Microsoft were the developers of Bash:
They would have sat on the bug for 20 years too if there were no known active exploits of it.
The first patch would have taken 30 days, not under 2 weeks (I don't know the real number, but it wasn't very long; and certainly under 2 weeks if not under 1 week).
The second patch would have still been needed, but would have taken yet another 30 days
Only a few developers would have had access to be able to review and fix anything
Password security is only partially maintained through what the user does.
If you care about password security you also have to think about the server-side. And there we are doing things that are also just as bad as passwords are often stored using a single encryption algorithm if they are encrypted at all; and often that algorithm is a simple MD5 or SHA1 hash of the password.
In addressing the server-side, we must also make things more variable by introducing settings that the server administrators set. The password is split according to the rules with each part passed through different algorithms, and the results merged using rules as well. One part of the password might pass through scrrypt, while another may pass through SHA512, and only portions used to get what is stored on disk.
Like it, but it needs a heatsink - or at least it ships from Amazon with one. So it's likely a little too hot for many applications RasberryPi works fine well for.
Despite the superiority of C#, my experience is that VB.net is by far the dominant language in (enterprise).net shops, and (enterprise).net is about as popular as Enterprise Java in practice.
Two major reasons:
- People are very familiar with VB and can program in VB.net easily.
- Lots of critical custom business apps were written in VB in the 1990s. As the software has been migrated to the web, VB.net allowed large amounts of source code containing critical business logic to be literally cut and pasted over.
The summary is completely absurd. VB.net will be around for another 25 years, at least.
I've done VB (VB5, VB6) programming and VB.net programming. There were so many subtle differences between VB6 and VB.net that a vast majority of the VB programmers continued with VB6. Code didn't get migrated in the sense that it did for VB5 to VB6 where all you had to do was reload and recompile - it got completely re-written going from VB5/6 to VB.net. It was a long standing complaint for 5 or so years after VB.net was released.
Now so much has been re-written, that it's probably not as a big a deal and VB.net may have taken over as a result. But I can certainly guarantee you that VB6 stuff is still out there and won't be rewritten for VB.net; probably will still be when VB.net goes away.
How are people not aware of DSLReports and their speed tests? And how could this possibly make/.?
Also, your wi-fi sucks. Get a cable if you want to know what your real speed is.
The ISPs cheat for the speed tests by temporarily increasing your bandwidth so that the tests detect a higher transfer rate than what they are actually giving you. They don't even prioritize just the DSL testing sites either; at least AT&T DSL doesn't.
Speed test sites don't need to be in collusion. ISP's just prioritize their traffic. It's quite obvious with my ISP if I do speed test sites versus just finding something large to download from a cloud storage service.
The obvious issue with that thesis is that you can't prove that the cloud storage site itself is performing slowly due to a bottleneck where it peers with your provider (or many other possible reasons) and while some providers are generally better than others about managing internal bandwidth, none can be said to have ALL uncongested peering points to ALL local customers and this obviously will have the same negative impact on user experience as a locally congested network.
I've actually used the SpeedTest sites to help improve downloading of Linux DVD ISO images. When I started the download (FTP/HTTP download) the quoted time was well over 8 hours, and the transfer rate was abysmal (60KBps to 120KBps on a multi-MBps line). Out of curiosity I ran a speed test through DSLReports and then found that the download rate jumped to 300KBps. After a while it would drop back to down to the previous range; I'd run the speed test again and voila, but up it went. I ended up downloading the entire Linux DVD ISO in under 1hour.
FYI, that was on AT&T DSL - not uVerse, just plain DSL since that is all we can get in our apartment. So obviously the ISPs are padding the numbers; which is a natural outcome of the FCC wanting people to report the ISPs that are not holding up.
As for VB, it'll remain as long as Microsoft Office is used in companies. It's way too handy and there's no alternative.
VB != VBA != VB.net
They only said VB.net will go away (at least in the summary). Most VB programmers stuck with VB instead of moving to VB.net because it was such a substantial change to go to VB.net.
VBA will never go anyway so long as MSO doesn't add support for other stuff, but even then there's so much written in VBA that it will only die when MSO dies.
Just playing devil's advocate, but you need to look at the medical information out there...
b) Rape babies should be aborted. Period. Why force someone to endure that, only to have them be reminded of their rapist, or have the baby put in a foster home/adoption.
Because as medical and psychological studies have proven it is healthier for the mother.
Abortion has a very nasty depression side-effect psychologically.
Abortion is almost always not safe to perform outside of the early cases like the morning-after pill.
One problem...pro-lifers advocate giving the children up for adoption instead of killing the child in-utero. In other words, responsibility after birth as well.
On the other hand, abortions have nothing to do with the health and safety of the mother - it's medically proven that that is not the case, both physically and psychologically - except in extreme cases that most pro-lifers would still allow abortions to occur under. The big issue comes down the embroynic stem cells that are generated and the inability to get them from pretty much any other source.
Just stop paying the subscription and inform to them upfront that you consider them to have terminated the contract through their own negligence.
Go elsewhere.
DO NOT do that without talking to your lawyer first.
But then, we should be using gallons-per-mile instead of miles-per-gallon, too.
A car that does 50MPG is twice as efficient as one that does 25MPG. What's so hard about comparing numbers in MPG? It sounds like me like someone's got a case of the "technically correct"s.
Because they're all bad numbers.
Honestly, we should be doing it in gallons/minute or gallons/hour (or litre/minute, litre/hour respectively), and move to single-speed engines that operate at peak efficiency that simply power an electric drive train (measured in KW/mile and KW/km). You'll get much more meaningful information regarding the efficiency of the vehicle.
As it stands, MPG/KmPG doesn't take into account how long you idle at lights, in traffic, etc. A good chunk of driving is completely missed in the calculations, assumed to be accounted for by the accel/decel in the structure of the testing. Only reason we do MPG/KmPG is due to the variable speed ICE systems we deploy in the vehicles instead of systems like http://www.bbc.com/autos/story...
Slashdot Mirror
It would sell because its marketed as windows, and then customers would be disappointed because it didnt do the same things their desktop windows does. After a short while, it would earn itself a terrible reputation and people would avoid it, and the existing unwanted devices would show up on ebay very cheaply.
On it's own merit, windows rt offers nothing over android or ios, and at $200 the hardware would at best be the same spec as $200 android hardware if windows were given away for free. On the other hand, its unlikely to be free, so the hardware would be inferior to cover the cost and then you also have a much smaller pool of apps than android/ios devices have.
TFA is about Servers, not Desktops. Windows Servers tend to run specialized software already - Exchange, MS SqlServer, Oracle Database, etc. Yeah, there'd likely be some complaints regarding stupid admins; but the Server world is looking at using ARM-based systems especially in datacenters b/c they are cheaper to run and easier to scale out due to lower heat generation (which Intel has always been bad about).
This is just MS saying "we don't want to be left out" since Linux is currently able to take on all these ARM datacenter systems.
So if (when) they do release it, expect it to first hit the "Windows Server Data Center Edition" as an alternate version for use and "Windows Server Standard" so that devs have something to test with; or they may just keep the initial few releases to only supporting Microsoft Software (e.g. Exchange, SQL Server, etc); and don't be surprised if you see that configuration in Microsoft Azure before it goes out to anyone else either.
I agree, but I think they may be taking this into account. For one, having a detailed mapping of somewhat technically engaged populace gives them just a little more information in regards to determining what segments of the population to randomly select for enhanced census. I know they are supposed to try to hit everyone but with just the right emphasis on how hard to try in certain areas, the results can be skewed enough to matter.
Well, more accurately it can tell them when they've achieved a statistically significant portion of the region in order to deem the census valid without having to get 100% and know they have a statistically relevant/reliable number, making it easier to account for the people not being home, etc.
Of course, they'll also "know" your home under the assumption you didn't forget your cellular device(s) at "home" that day.
The problem is MS never had a small tutorial during windows installation or during the first boot showing users how to create a Standard User account and have an administrative account for elevating your rights for doing administrative stuff. But now, with windows 8 during the install, you can create any type account you like, but again, no tutorial.
The problem is one of history for Windows.
Windows was originally a place where every user was an Administrator. This encouraged developers to not pay attention to APIs used, so then applications came to be reliant on running only under users that were Administrators. Even Microsoft Office did that for a long time.
Then Microsoft split users up and now there was a special Administrator account and group. Except users wanted to continue using all the software they had from before that split. The solution? Make all users administrators. Developers kept designing software that required administrative access - even Microsoft Office.
Then came Windows Vista and UAC. Microsoft Office got fixed up; but many developers did not listen to years of warning. So then UAC started prompting the hell out of everyone. Windows 7 came along and most developers had fixed their software so UAC could be scaled back in its prompting some (really, that's the only difference between Win7 and Vista - the default threshold setting for UAC - in this matter).
Of course no where along the road did Microsoft make it easy to switch between users. Sure, there's "Run As..." but it's (a) not well known, (b) a PITA to use, and (c) doesn't solve every use case. UAC doesn't quite either. In neither case do either work like the priviledge escalation in Linux/Unix with "su" and "sudo" and their graphical equivalents. So everyone still must have the administrative access to do certain tasks.
And of course people are still trained that their user needs to be the Admin user for the system.
So there's still work to be done on Windows to bring a real "su"/"sudo" experience to Windows; but overall it's still very much a user issue since they're all trained to and expect that their Windows user will have admin rights whether they really need them or not.
It's mildly funny that Server 2003 doesn't have this bug, and also was the last Windows Server that still used some Unix/BSD code.
(No, I'm not claiming a causal relationship...)
Which makes me think that WinXP was also not affected as it was closely related to Windows Server 2003. However, it's no longer supported so...
The company is not interested in supporting the software. So if their software is in peril, it is entirely in their hands.
This situation doesn't sound unusual to me. The company originally developed it because it addressed a need/demand at the time. The developers involved took a personal interest in it. The original need has long gone, but the developers have kept it going as a personal project that the company indulges.
But once the original developers leave, the company has no reason to continue their involvement with it. The people using it are not their customers (or are insignificant enough to be customers of no value). They owe it nothing, and suffer no "embarrassment" from walking way from it.
That being said, I don't know why the poster hasn't come out and said what the software is. It may answer a number of questions.
It could be that they haven't announced anything yet, so it could cause "material harm" to the company or put the TFA's author in a bad position in the company to announce something prior to any official annoucement. There are numerous legal reasons to not necessarily name a project; however much the community here may want them to do so.
Apache
Apache requires 2 active backers for them take the project. They don't just accept dead cruft; there has to be a community.
Also a Dice holding. Bitbucket or github are in better shape these days.
Wow! You guys are fast!!
I never expected someone to guess the right name of the project with only the two clues I've given.
GNU already has a fork of that project - http://savannah.nongnu.org/
Why? You'd have the gov't spend money to overbuild or be able to scale a website for the one time every few years it gets overloaded? Seems like a waste of money to me. It does just fine 99.9999999% of the time.
The other issue was that all the news articles said things like, "X Million Hondas Recalled!" As a Honda Accord owner, I clicked on the article and looked, only to discover it was for rather old Accords (nothing newer than like 2003; ours is a 2012). Others probably went to safercar.gov instead, only to find it didn't apply. (That headline should have been in the favorite clickbait poll. "X Million Cars from 1998-2003 recalled!" would have been better, but...fewer clicks!)
Recall applied to many more than just Hondas, and many different model years even outside the 1998-2003 years you quoted. So sure, car's model may not have had an issue, but many others did.
Also, safecar.gov forwarded to the other site so that didn't really make a difference.
Finally, I would expect any organization that has a mission like that of the site in question to be prepared should a major issue like this happen, primarily because it could happen at any time and they are the central source of information. The fact that it is a government website only makes it more important to be able to scale.
Your argument is like saying that the IRS website need not scale b/c it works just fine for 350 days of the year; it's only less than 15 days of the year that it sees major amounts of traffic. Sorry - but that doesn't work and safety should have a higher burden of reliance than the IRS.
Then they were fools. The whole point of buying an established company is to buy the brand as well as the factories. Anyone can build a factory, usually for no more than it would cost to buy someone else out.
Except they weren't trying to buy the "brand". They were trying to buy the product to ensure that there was an actual product in the market with their failing OS on it; they were simply trying to buy market share; nothing more.
The fact that it's their name on it now won't change anything. It will still fail just as a badly as before (may be even worse).
Is a website buckling under load? Let's publish more articles about it and drive more traffic to their site!
It was buckling before it hit Slashdot; but yes they should be able to do better.
And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited
Can you please cite the policy? A quick glance through the Microsoft Security Bulletins reveals that most of them have not been actively exploited before being patched.
Of course you could argue that Microsoft is lying, but many security researchers do (privately) report vulnerabilities to Microsoft, and you really don't think some of them will publicize the bugs if they aren't fixed in, like, a year?
Or are you actually trying to say they don't fix them unless they have been reported, which is an entirely different thing?
Microsoft does not publicize all vulnerabilities reported to them; and not every reporter will publicize it either. So how many they actually know about is unknown. This is reported by most people that are writing about the issue, especially those comparing Microsoft's practices to Open Source's and comparing the numbers for the CVE reports between the groups.
I didn't say MS was better, I said the bash response was poor, and the poster I replied to couldn't possibly have had fixes in place within minutes as claimed.
I'm just pointing out that however poor the Bash devs response was, Microsoft's would have been worse.
Oh, and in your argument "up to 30 days" suddenly becomes "taken 30 days" - actually if bugs come in uniformly distributed in the 30 day cycle then average would be 15 days, or lower since sometimes they do go out-of-band.
Actually, my comment regarding "taken 30 days" for Microsoft is well founded in their historical turn-around for CVEs that they have acknowledged as being fixed. With a rare exception, they don't deliver any patches in under 30 days; and even 30 days is being gracious as it's usually more like 6 months so I'm already putting them on their own expedited schedule for such fixes.
Again, pointing out that however poor the Bash devs response was, Microsoft's at it best is worse.
Plus, the second (and third and fourth and so on) patches are only needed if the first (and second and third.,.) one is inadequate and not properly tested.
If the numerous people reviewing Bash, from multiple companies, and disciplines didn't find the issue with the first patch, then how would Microsoft with a far more limited set of people looking at the code be able to get the same kind of patch correct the first time and get all the corner cases figured out and fixed before releasing the first patch?
I'm not saying the Bash devs had 1 million eyes on this; but they certainly had a few hundred if not a thousand or so in total. Microsoft's equivalent group probably is no greater than 50 devs at best, likely smaller; and probably no where near the cross-discipinary skill set match either.
So if the Bash guys had to do a second patch (or even a third, etc) to fix it; chances are Microsoft would have had to have at least as many patches too.
Maybe MS are just as bad at that too, but the developers of Bash were certainly not good at it.
Agreed - kinda. The main point of the origin of this thread (article?) was that F/LOSS software could not deal as well as proprietary software; that somehow the proprietary vendors could do better with these kinds of bugs - both catching them and responding to them.
;-)
My point, is that based on its history - documented in numerous articles over the years - Microsoft is a prime example of showing that's not the case. That proprietary vendor's own policies and procedures prevent them from delivering anywhere near as good a turn around.
But here's the kicker - there is a similar exploit for cmd.exe. It's yet to be patched.
here's an example: https://twitter.com/FioraAeter...
(And yes, I've seen it from other sources, just don't have those links right now.)
What should really happen is Mr. Rossi should patent his device, and then anyone who wants to can read the patent and build their own replica, if they wish to do so. (Of course to sell their replica they would need to license the design from Mr. Rossi, since it would be patented)
Perpetual Motion Machines (and Cold Fusion) require a working device to receive a patent. There have been so many hoaxes that the US PTO (at least) wants a physical machine they can inspect in order to issue the patent.
#isisforobama
Fixed that for you.
How did you fix them in minutes when it took several days for correct patches to come out, for entirely predictable reasons (laughable approach of trying to find and fix all bugs at once in a parser never designed to be secure, when the real issue is that it should never be being fed untrusted input) ?
To my mind, that is the biggest failure of open source / free software in this case - 20+ yr old bug / insecure-feature in an obscure corner of a system never designed for today's threat environment - forgiveable - responsible disclosure, working with maintainers under embargo - good - publication along with a patch that was broken again within hours if not minutes - fail - everyone and his dog then panic-issuing further patches for one parser vulnerability after another before eventually someone (actually more than one different approach) fixes it properly the way it should have been done in the first place - spectacular fail
And yet Microsoft has a known policy that they don't fix any exploit proven or not unless it is actively being exploited; when an unknown exploit is exploited they take up to 30 days to release, and that still may not have everything fixed. So to put this in context, if Microsoft were the developers of Bash:
Password security is only partially maintained through what the user does.
If you care about password security you also have to think about the server-side. And there we are doing things that are also just as bad as passwords are often stored using a single encryption algorithm if they are encrypted at all; and often that algorithm is a simple MD5 or SHA1 hash of the password.
In addressing the server-side, we must also make things more variable by introducing settings that the server administrators set. The password is split according to the rules with each part passed through different algorithms, and the results merged using rules as well. One part of the password might pass through scrrypt, while another may pass through SHA512, and only portions used to get what is stored on disk.
Banana Pi is $49, dual-core, 1GB RAM
Like it, but it needs a heatsink - or at least it ships from Amazon with one. So it's likely a little too hot for many applications RasberryPi works fine well for.
Despite the superiority of C#, my experience is that VB.net is by far the dominant language in (enterprise) .net shops, and (enterprise) .net is about as popular as Enterprise Java in practice.
Two major reasons:
- People are very familiar with VB and can program in VB.net easily. - Lots of critical custom business apps were written in VB in the 1990s. As the software has been migrated to the web, VB.net allowed large amounts of source code containing critical business logic to be literally cut and pasted over.
The summary is completely absurd. VB.net will be around for another 25 years, at least.
I've done VB (VB5, VB6) programming and VB.net programming. There were so many subtle differences between VB6 and VB.net that a vast majority of the VB programmers continued with VB6. Code didn't get migrated in the sense that it did for VB5 to VB6 where all you had to do was reload and recompile - it got completely re-written going from VB5/6 to VB.net. It was a long standing complaint for 5 or so years after VB.net was released.
Now so much has been re-written, that it's probably not as a big a deal and VB.net may have taken over as a result. But I can certainly guarantee you that VB6 stuff is still out there and won't be rewritten for VB.net; probably will still be when VB.net goes away.
How are people not aware of DSLReports and their speed tests? And how could this possibly make /.?
Also, your wi-fi sucks. Get a cable if you want to know what your real speed is.
The ISPs cheat for the speed tests by temporarily increasing your bandwidth so that the tests detect a higher transfer rate than what they are actually giving you. They don't even prioritize just the DSL testing sites either; at least AT&T DSL doesn't.
Won't work if it's widely known.
Speed test sites don't need to be in collusion. ISP's just prioritize their traffic. It's quite obvious with my ISP if I do speed test sites versus just finding something large to download from a cloud storage service.
The obvious issue with that thesis is that you can't prove that the cloud storage site itself is performing slowly due to a bottleneck where it peers with your provider (or many other possible reasons) and while some providers are generally better than others about managing internal bandwidth, none can be said to have ALL uncongested peering points to ALL local customers and this obviously will have the same negative impact on user experience as a locally congested network.
I've actually used the SpeedTest sites to help improve downloading of Linux DVD ISO images. When I started the download (FTP/HTTP download) the quoted time was well over 8 hours, and the transfer rate was abysmal (60KBps to 120KBps on a multi-MBps line). Out of curiosity I ran a speed test through DSLReports and then found that the download rate jumped to 300KBps. After a while it would drop back to down to the previous range; I'd run the speed test again and voila, but up it went. I ended up downloading the entire Linux DVD ISO in under 1hour.
FYI, that was on AT&T DSL - not uVerse, just plain DSL since that is all we can get in our apartment. So obviously the ISPs are padding the numbers; which is a natural outcome of the FCC wanting people to report the ISPs that are not holding up.
As for VB, it'll remain as long as Microsoft Office is used in companies. It's way too handy and there's no alternative.
VB != VBA != VB.net
They only said VB.net will go away (at least in the summary). Most VB programmers stuck with VB instead of moving to VB.net because it was such a substantial change to go to VB.net.
VBA will never go anyway so long as MSO doesn't add support for other stuff, but even then there's so much written in VBA that it will only die when MSO dies.
b) Rape babies should be aborted. Period. Why force someone to endure that, only to have them be reminded of their rapist, or have the baby put in a foster home/adoption.
Because as medical and psychological studies have proven it is healthier for the mother.
Abortion has a very nasty depression side-effect psychologically.
Abortion is almost always not safe to perform outside of the early cases like the morning-after pill.
Now that babies are born to people who are poor
One problem...pro-lifers advocate giving the children up for adoption instead of killing the child in-utero. In other words, responsibility after birth as well.
On the other hand, abortions have nothing to do with the health and safety of the mother - it's medically proven that that is not the case, both physically and psychologically - except in extreme cases that most pro-lifers would still allow abortions to occur under. The big issue comes down the embroynic stem cells that are generated and the inability to get them from pretty much any other source.
Just stop paying the subscription and inform to them upfront that you consider them to have terminated the contract through their own negligence. Go elsewhere.
DO NOT do that without talking to your lawyer first.
But then, we should be using gallons-per-mile instead of miles-per-gallon, too.
A car that does 50MPG is twice as efficient as one that does 25MPG. What's so hard about comparing numbers in MPG? It sounds like me like someone's got a case of the "technically correct"s.
Because they're all bad numbers.
Honestly, we should be doing it in gallons/minute or gallons/hour (or litre/minute, litre/hour respectively), and move to single-speed engines that operate at peak efficiency that simply power an electric drive train (measured in KW/mile and KW/km). You'll get much more meaningful information regarding the efficiency of the vehicle.
As it stands, MPG/KmPG doesn't take into account how long you idle at lights, in traffic, etc. A good chunk of driving is completely missed in the calculations, assumed to be accounted for by the accel/decel in the structure of the testing. Only reason we do MPG/KmPG is due to the variable speed ICE systems we deploy in the vehicles instead of systems like http://www.bbc.com/autos/story...