In her defense, what the hell does that matter? I've travelled to a number of foreign countries and couldn't have told you who the prime minister was. I don't check up on state governors when I cross state lines. You almost certainly don't know her grandmothers name, or her agents name, or the engineer who recorder her last album. Because you don't care. I don't especially care who the PM of England is, whther I'm there or not. You're confusing "She doesn't know the same things I do" with "She's stupid".
None of which to say that she might not be stupid - she's certainly done some crazy/foolish things and knowing what little I do about her background it wouldn't suprise me to know that she's a few bricks short of a load.
Because there's no such thing as "security" when you're streaming files. Think about what you said - you need to have an mechanism for authentication, which is both secure and usable. You need to have a mechanism for identifying which files are accessible and which are not, and the user of your component needs to configure it correctly and with knowledge of what he's sharing. Think back a few years to all those people who shared entire hard drives on P2P apps, or who have web servers/file shares set up sharing their entire machine. The security implications of exposing files have very little to do with the actual mechanisms of sharing files, it's the meta-information that's important and thats is (and must be) in the hands of the end user.
Writing secure applications in a hostile environment is hard. There's no silver bullet, and PHP is especially egregious with it's history of insecure library functions and the encouragement of insecure programming (slowly getting better, but the typical PHP application is still a morass of SQL injection and data exposure vulnerabilities). The correct answer is education, and language/library changes to *discourage* the sort of insecure programming that people do, not giving an illusion of security through "secure widgets". A good start might be a functional database interface that doesn't permit the execution of arbitrary strings as SQL.
This attitude is in no small part responsible for the generally terrible security of web-based applications. Security is *not* a set of "audited widgets". You have to know what to do and what not to do - there's no magic widget that is going to secure your application. You *can't* write a general purpose, secure widget for exposing files over the internet without the end developer knowing what they're doing.
This still isn't a bug. If it's a supported and desirable feature of the web application, then they need to support it themselves. Otherwise it's a perfectly legitimate and standards-compliant way of handling per-session cookies - and Firefoxes way of handling it is potentially much more secure when it involves things like banking. I can see a case being made for wanting the other behavior, but it's a feature request/behavior change that could(should?) be decided on by voting, not a bug that needs to be addressed.
People have been doing this for a long time, although the readers on gas pumps would be more difficult. That's why we don't have the things that hold your card anymore, by the way.
Naturally, though, it's not plain old American criminals, it's Evil Nasty Terrorists(tm).
A quick correction: no, they will not, no matter how much "proof" you come up with. They won't even look at it. You're considered responsible for making sure that everything stays safe. No, you can't back up your install CDs.
It does depend to some degree on the assumption that opposition to the regime is roughly evenly spread over jobs: the army, weapon manufacturers, the people working at the control points. You are right about that.
I'd say you're a pretty lousy ruling elite if you don't make sure that control of whatever makes you elite stays in your hands, though. Maybe he only meant stupid ruling elites:P
In the late 19th century, Kuyper (you will not know him unless you happen to be Dutch) argued that a people, by virtue of numbers, is always able to remove its elite as long as you ignore cross-border effects.
Hogwash, unless you get persnickety with the definition of cross-border. There's all sorts of control points on a nation, and you don't generally need to be a majority to have them. Historically, technology has been used. The pyschological advantage of control can't be overestimated either, slavery is a good example here. Control of water sources is a great way for a minority to control a majority.
Kuyper may have meant that if the majority didn't care for their own losses, and manged to throw off all the chains of psychological and class warfare, then they can always overcome the ruling minority. That's true to a point, but I'd take issue with the "always". Take prison riots as a counterexample, which occasionally succeed, but more often are suppressed.
Kuyper's statements make for good rhetoric and probably morale lifting speeches but kinda fall apart in the real world.
This is the core of opposition to the current prison system. You aren't interested in justice or health or the benefit of society - you want revenge. There are a lot of people who believe that your reasons for wanting that are harmful and that it's not a good way to run a society.
And, as you have no doubt noticed, I have to largely agree. Relatives of a victim are the last people we should be listening to, because they are the least likely to think clearly or rationally about anything. You see this all the time with high-profile legal cases - people decide based on emotion rather than facts. Being arrested for, say, child molestation will basically ruin your life no matter how ridiculous the evidence is, and whether you're convicted or not.
Sucessfull OSS projects almost always either a) make a point of remaining compatible, so at the very least you can do side-by-side installations or b) outcompete all competition so the losing forks become marginalized and eventually ignored. This is very similiar to how the real software market works, by the way. You're comparing one successfull product ("Windows") to a whole market ("OSS"). It's more accurate to look at OSS as a model of what the commercial software industry should look like. Think about what kind of software we'd have if Apple, Microsoft, and... say... Sun all had roughly equal desktop market share.
The problem is that the commercial software market is ridiculously unhealthy, due in large part to the MS monoculture, and this affects peoples view of what is "correct".
Political or personal reasons are often perfectly valid reasons to fork. OSS developers are as human as anyone else, and there are (often) personality clashes and conflicts. If you're too annoying to work with, don't be suprised if either the project forks out from under you, or if you you end up forking away your own project.
And the detriment is involved how? People who claim that forks weaken a project don't understand how open source works. These are volunteers - they work on things that interest them and in the way which interests them. If you somehow had the power to force work on GNOME to stop, what would not happen is that all the people would then go work on KDE. KDE isn't harmed by the existence of GNOME. People who think that having both makes the Linux desktop weaker are ignorant.
Note that I'm not arguing that it doesn't harm adoption of Linux on the desktop, just that the reasons it does so are out of ignorance.
Have to agree here. DrawText() is a very slow call because it tries to produce high quality text. If you're willing to dispense with stuff like kerning, anti-aliasing and, Unicode support, you can roll your own text output in just a few lines of code that's orders of magnitude faster. However, I strongly suspect that your problem is too many calls to DrawText() rather than DrawText() being too slow.
Fix your crappy rendering algorithms:p Seriously, algoithmic problems are probably your biggest enemy. Especially if you're basing everything off of MFC, which doesn't lend itself to optimized drawning. I can't possible emphasize how much you shouldn't re-produce the entire UI in DirectX.
Have you actually benchmarked and you're sure it's drawing thats the problem? The only time I've ever seen this has been in very complicated 2d visualization and graphing applications (stuff like MRE renders). Every other case where the "GUI was slow" was really a combination of poor drawing code (one application I saw re-painted 5 times for every data update) and poor algorithm choice/implementation. Switching to DX might highlight some of those problems for you.
Save at exit of the page is possible, if the brower allows you to veto navigation. Save at exit of the browser is totally impossible, and is what I was talking about.
What's stopping it from happening is that the features that make a good browser for hypertext are not the same features that make a good client for, say, a business or data entry application. As a quick test, go hit the back button in any web application that uses this sort of technology. Does it do what you expect? Does the "back button" even make sense in the context of what you're doing?
Hypertext is a lousy way of writing applications - in fact, most "web apps" have roughly zero relationship with hypertext. Network-transparent thin clients are interesting, but HTML/DHTML/current browsers are the wrong way to implement these things. Part of the problem is the issue of control - client applications need to be able to control the user interface to a degree that a general purpose browser simply can't allow. Something as simple as "Save changes at exit" is impossible in a browser - and you wouldn't want it to be. Same thing with control of the back button, or spawning new windows (or even dialogs, which you can do with IE).
In short - the browser is a fundamentally poor platform for most applications. More to the point, we have and have had the technology for network-based application suites for years. ASP (application service providers, not the MS web platform) is gaining some mindshare, but it's not taking off like gangbusters.
Eh. Not really. Auto-updating isn't especially difficult, especially in the close environments most web applications are written for. Java Web Start, for example, is a cinch. It's not too hard to roll your own mechanism either. Web applications are trendy now, though, despite there being no objective advantage in most circumstances.
Refresh-less updating isn't new, either - I've been doing it for at least 3 years, without the XML stuff. Even with it there's only so much you can do on the client, by design. The web is a decent platform for reporting. It's a good place for universal access (see gmail, for example). It's a lousy place to put your data-entry heavy business applications.
The plural of anecdote isn't data.... I've seen guys with a Masters in Comp Sci write the same sort of garbage. As a disclaimer, I'm self taught. I also wouldn't (and don't) write code like that.
I disagree with the willingness to expiriment and self-motivate being teachable - they're something that people either have or don't have. Someone who's (effectively) self-taught will neccesarily have them, but being a graduate certainly doesn't preclude it, either. One problem with being self-taught is the gaps in knowledge where you've never run into anything - I have trouble with the higher math involved in 3d programming, for example, and have considered taking some online or night classes to remedy that. But, to be fair again, the longer you're out of school the rustier your skills in areas you don't exercise will be. My calc is lousy cause I never formally learned it, but it's not really much worse than the guy next to me who hasn't used his in 10 years.
Are you telling me that there's NOT legal precedent for the provider of a service to define the terms of service? Unlike retail software, MMORPGs are unambiguously a service.
Of course, something like 80% of crashes are due to pilot error....
Shit does happen. People skip over items on checklists every day. Little things break constantly. Usually it's not enough to cause a catastrophic failure. Now, whoever was in charge of the specific checklist DID screw up, and they screwed up hard, and they need to own up to that. But the potential for failure is part of complex systems and the human element is part of that.
The OPs rant about software is just stupid, though. Software is complicated, and it is hard, and one of the ways you battle that is by reducing scope, like he does for his embedded systems. But there's a limit to how much complexity you can toss away, and the more complex your software the harder it is to verify it.
That's totally aside from the other human element involved, which is that people who won't blink twice over having two totally redudant billion dollar datacenters won't authorize 6 months of testing.
Science is about quality not quantity, so they were wrong to do that.
This is totally false, as an scientist will tell you. Quantity is a characteristic of quality. In this case, splitting the data stream is actually the best choice, because you get both redudency of the communications infrastructure, but you also get redundency of data. The thing to remember is that there was a limited communications window and increasing bandwidth meant that the quality of the data they were going to get back would be greatly increased. They didn't affect redudency because, while they didn't get exactly the same data, they got a working subset of it.
Slashdot Mirror
None of which to say that she might not be stupid - she's certainly done some crazy/foolish things and knowing what little I do about her background it wouldn't suprise me to know that she's a few bricks short of a load.
Writing secure applications in a hostile environment is hard. There's no silver bullet, and PHP is especially egregious with it's history of insecure library functions and the encouragement of insecure programming (slowly getting better, but the typical PHP application is still a morass of SQL injection and data exposure vulnerabilities). The correct answer is education, and language/library changes to *discourage* the sort of insecure programming that people do, not giving an illusion of security through "secure widgets". A good start might be a functional database interface that doesn't permit the execution of arbitrary strings as SQL.
This attitude is in no small part responsible for the generally terrible security of web-based applications. Security is *not* a set of "audited widgets". You have to know what to do and what not to do - there's no magic widget that is going to secure your application. You *can't* write a general purpose, secure widget for exposing files over the internet without the end developer knowing what they're doing.
This still isn't a bug. If it's a supported and desirable feature of the web application, then they need to support it themselves. Otherwise it's a perfectly legitimate and standards-compliant way of handling per-session cookies - and Firefoxes way of handling it is potentially much more secure when it involves things like banking. I can see a case being made for wanting the other behavior, but it's a feature request/behavior change that could(should?) be decided on by voting, not a bug that needs to be addressed.
Does it hurt when you're so totally amazingly and in all ways completely wrong?
You know a lot of people with 4 letter last names?
Naturally, though, it's not plain old American criminals, it's Evil Nasty Terrorists(tm).
Cloudscape looks really nice. I'm not a Java guy, though, so I use SQLLite (http://www.sqlite.org/) as my embedded database.
A quick correction: no, they will not, no matter how much "proof" you come up with. They won't even look at it. You're considered responsible for making sure that everything stays safe. No, you can't back up your install CDs.
I'd say you're a pretty lousy ruling elite if you don't make sure that control of whatever makes you elite stays in your hands, though. Maybe he only meant stupid ruling elites :P
Hogwash, unless you get persnickety with the definition of cross-border. There's all sorts of control points on a nation, and you don't generally need to be a majority to have them. Historically, technology has been used. The pyschological advantage of control can't be overestimated either, slavery is a good example here. Control of water sources is a great way for a minority to control a majority.
Kuyper may have meant that if the majority didn't care for their own losses, and manged to throw off all the chains of psychological and class warfare, then they can always overcome the ruling minority. That's true to a point, but I'd take issue with the "always". Take prison riots as a counterexample, which occasionally succeed, but more often are suppressed.
Kuyper's statements make for good rhetoric and probably morale lifting speeches but kinda fall apart in the real world.
And, as you have no doubt noticed, I have to largely agree. Relatives of a victim are the last people we should be listening to, because they are the least likely to think clearly or rationally about anything. You see this all the time with high-profile legal cases - people decide based on emotion rather than facts. Being arrested for, say, child molestation will basically ruin your life no matter how ridiculous the evidence is, and whether you're convicted or not.
The problem is that the commercial software market is ridiculously unhealthy, due in large part to the MS monoculture, and this affects peoples view of what is "correct".
Political or personal reasons are often perfectly valid reasons to fork. OSS developers are as human as anyone else, and there are (often) personality clashes and conflicts. If you're too annoying to work with, don't be suprised if either the project forks out from under you, or if you you end up forking away your own project.
Note that I'm not arguing that it doesn't harm adoption of Linux on the desktop, just that the reasons it does so are out of ignorance.
Have to agree here. DrawText() is a very slow call because it tries to produce high quality text. If you're willing to dispense with stuff like kerning, anti-aliasing and, Unicode support, you can roll your own text output in just a few lines of code that's orders of magnitude faster. However, I strongly suspect that your problem is too many calls to DrawText() rather than DrawText() being too slow.
Have you actually benchmarked and you're sure it's drawing thats the problem? The only time I've ever seen this has been in very complicated 2d visualization and graphing applications (stuff like MRE renders). Every other case where the "GUI was slow" was really a combination of poor drawing code (one application I saw re-painted 5 times for every data update) and poor algorithm choice/implementation. Switching to DX might highlight some of those problems for you.
Save at exit of the page is possible, if the brower allows you to veto navigation. Save at exit of the browser is totally impossible, and is what I was talking about.
Hypertext is a lousy way of writing applications - in fact, most "web apps" have roughly zero relationship with hypertext. Network-transparent thin clients are interesting, but HTML/DHTML/current browsers are the wrong way to implement these things. Part of the problem is the issue of control - client applications need to be able to control the user interface to a degree that a general purpose browser simply can't allow. Something as simple as "Save changes at exit" is impossible in a browser - and you wouldn't want it to be. Same thing with control of the back button, or spawning new windows (or even dialogs, which you can do with IE).
In short - the browser is a fundamentally poor platform for most applications. More to the point, we have and have had the technology for network-based application suites for years. ASP (application service providers, not the MS web platform) is gaining some mindshare, but it's not taking off like gangbusters.
Refresh-less updating isn't new, either - I've been doing it for at least 3 years, without the XML stuff. Even with it there's only so much you can do on the client, by design. The web is a decent platform for reporting. It's a good place for universal access (see gmail, for example). It's a lousy place to put your data-entry heavy business applications.
Use PostgreSQL instead of MySQL and you can re-factor it to LARP!
I disagree with the willingness to expiriment and self-motivate being teachable - they're something that people either have or don't have. Someone who's (effectively) self-taught will neccesarily have them, but being a graduate certainly doesn't preclude it, either. One problem with being self-taught is the gaps in knowledge where you've never run into anything - I have trouble with the higher math involved in 3d programming, for example, and have considered taking some online or night classes to remedy that. But, to be fair again, the longer you're out of school the rustier your skills in areas you don't exercise will be. My calc is lousy cause I never formally learned it, but it's not really much worse than the guy next to me who hasn't used his in 10 years.
Are you telling me that there's NOT legal precedent for the provider of a service to define the terms of service? Unlike retail software, MMORPGs are unambiguously a service.
Shit does happen. People skip over items on checklists every day. Little things break constantly. Usually it's not enough to cause a catastrophic failure. Now, whoever was in charge of the specific checklist DID screw up, and they screwed up hard, and they need to own up to that. But the potential for failure is part of complex systems and the human element is part of that.
The OPs rant about software is just stupid, though. Software is complicated, and it is hard, and one of the ways you battle that is by reducing scope, like he does for his embedded systems. But there's a limit to how much complexity you can toss away, and the more complex your software the harder it is to verify it.
That's totally aside from the other human element involved, which is that people who won't blink twice over having two totally redudant billion dollar datacenters won't authorize 6 months of testing.
This is totally false, as an scientist will tell you. Quantity is a characteristic of quality. In this case, splitting the data stream is actually the best choice, because you get both redudency of the communications infrastructure, but you also get redundency of data. The thing to remember is that there was a limited communications window and increasing bandwidth meant that the quality of the data they were going to get back would be greatly increased. They didn't affect redudency because, while they didn't get exactly the same data, they got a working subset of it.