... just to set off a loud siren like an air raid siren. Thats how they do it now: simple, and everyone can hear it day or night and knows what it means.
Well, now; I wouldn't make that claim. Just a month ago, for example, I was driving around in a city about 1200 miles from home, in the middle of the day, and a loud siren went off. I had no clue as to what it might mean. It wasn't near a shore; there was no threatening weather anywhere nearby; there were no large planes flying overhead. And the few hundred people I could see, who were probably mostly locals, were obviously ignoring it. So either they didn't know either, or they knew and were ignoring it. I did stop and ask one person, who just shrugged, said something like "Dunno; it goes off every day at around this time and we all just ignore it."
A century or more back, loud bells and/or sirens were fairly commonly used to publicly announce things like the time of day. This made sense when watches were fairly expensive, and helped organize things in factories and the like. But these days, that's not common, because watches and clocks are cheap (and it's getting hard to be out of sight of one).
So it might take quite a bit of publicity to get a population aware of the meaning of a siren. It would be especially difficult in the vicinity of a good beach, where much of the population could be vacationers and tourists. And standardizing such things would be difficult in much of the world.
Instead of trying to put such powerful lasers in orbit and dealing with the nightmare of servicing them, why not do the obvious: Transmit the data to the ground, and put the warnings on a group of web sites that can be checked by anyone.
Of course, most people in the world wouldn't be routinely checking that web site, especially when it goes for weeks without any tsunami warnings at all. Just as they wouldn't be routinely going outside every few minutes to check for a light in the sky that never seems to be there. What you'd also have to do is publicize your site with the relevant emergency and news agencies. If you could supply data accurate to the minute and danger estimates for various islands and coasts, I'd expect that the emergency and news people there would be interested, and would be happy to install software that pops up warnings on their screen when their coordinates appear on your site.
That way, you'd get the information widespread in a matter of seconds, and response wouldn't depend on people noticing a little light up in the sky. And the local emergency people wouldn't consider you competition. You'd just be a good source of information that would make them look like heroes to their local population.
You might also consider things like an RSS feed, a twitter account, and so on.
As I recall, there has been some research on the use of orbiting lasers to accurately measure sea-surface height. You might want to find what's been written about the topic. A quick google search for "orbiting lasers sea-surface height" gets about 84,000 hits right now.
This may be a result of "niche" searches, but I was very surprised that Bing basically didn't work.
Actually, Microsoft's managers of the bing project have publicly discussed the reasons for their problems, and you basically nailed it. They concentrated on finding the most common search phrases, and optimizing for those. (They probably got that information from google.;-) They've admitted that their optimizations only work for the roughly 1/3 of all requests that match their "common requests" list. For the other 2/3 of requests, which they've characterized as the "long tail", they admit that their approach fails as dismally as you've described.
Well, give them a few more years, and they'll probably announce yet another "new" search project that does a better job. Maybe it actually will. Or maybe it'll be another search site that fails for a new reason.
I suppose this failure is more excusable than the previous one, in which people quickly realized that they were returning "matches" pointing to their top advertisers rather than a page that had what you wanted. That one was also understandable, of course, and many people quickly realized that it was purely dishonest, in the sleazy-salesman fashion. Their latest failure is at least based on an attempt to handle search requests accurately and honestly; they just badly misjudged the variability of English phrasing and what this would mean to an approach that emphasized the most popular requests.
When 2/3 of our searches are classified as "niche" and not handled well, it's not surprising that people might look for something better. OTOH, this is true of pretty much everything that MS Windows does, and they still manage to get the overwhelming majority of sales despite handling nearly everyone's computing tasks so poorly that even dumb users routinely use obscenities to describe Microsoft products. But in the search arena, most users know a common verb that is the name of a good search site...
They'll use the default. They always use the default.
[Citation needed];-)
I've seen claims that under 2% of Windows users are using a browser other than IE. I've also seen claims that 20% of Windows users are using Firefox. I sorta suspect both of these statistice, for what are probably obvious reasons.
Does anyone have actual reliable numbers on such things? I mean, with accurate descriptions of their methodology, rather than just asserting a number and expecting us to believe it?
I do know lots of Windows users of the sort that view "the internet" as the blue "e" logo. They typically don't know what a browser is, or that they're using one. They also generally can't name a computer builder; they tend to think that computer brands are names like "Dell" or "IBM", and don't know that Apple is the name of a computer company.
However, I also know lots of Windows users who are at least familiar with Apple, Firefox, etc. Some of them actually profess to hating Microsoft, use Windows only because their job requires it, and have a Mac at home. (My wife does her job-required Windows work at home in a virtual partition on her iMac. This upsets the Microsoft fanboys at work no end, while other workers have asked her for help getting it working on their Mac.;-)
So my admittedly limited, unscientific survey says that "Windows users" are a varied lot. Some of them are dummies who just use whatever was installed on their "computer" (and that's all they know it is) when they bought it. Others consider themselves stuck with a crappy system but know a fair amount about making it less awful. I have little evidence of the proportions of such classes of users in the general Windows customer base.
Anyone know how to get reliable numbers, not just unsupported assertions?
It would be a very good thing if we could learn to distinguish between the academic, the artistic, and the business/engineering aspects of software. I don't know about you, but I really don't want to fly across an ocean in airliner designed by this year's latest and greatest methods, using revolutionary new materials that show great promise in some ways. Give me 747 or at least a 777...
Funny you should describe it that way, which is directly relevant to the topic at hand. I've worked on a couple of java projects were, out of curiosity, I wrote a little "Hello, world." program, and packaged it according to the project's official packaging rules. In each case, the result was a file over 50 MB in size. Sorta like using a 747 to deliver a postcard to a neighbor down the street.
Now, I'm quite aware that such monstrosities aren't the fault of java. Just like the existence of 747s doesn't negate the existence of ultra-light aircraft. But a corporation adapted to building a 747 or airbus probably wouldn't be the one you'd want to build your small aircraft. And a corporate software culture adapted to building the bureaucratic monstrosities that you see with java (or Cobol) probably isn't the software culture you want to build those apps for your slick new smart phone. (Or maybe I should say tablet, since today is the first sale of the iPad.;-)
Unfortunately, programming languages tend to come with cultures, and depending on who you are, such a culture can be very appealing or very off-putting.
Uh, no; C was the new assembly language 35 years ago. By 30 years ago, C had pretty much conquered all, and assembly was a relic surviving in only a few highly-specialized niches.
And a major problem with C for the past 20 years has been the attempts to make it into a good high-level language. The result has mostly been to make it materially more difficult to write good assembly-level code in C, while not producing a good higher-level language.
JSR 310 classes store date/time representations only as a nanosecond offset from the same standard epoch used by Date and Calendar; calendar fields such as day of month are only computed when needed and are not used for internal representation of dates.
Back in the late 1990s, I worked as a developer for a project that was mostly done in java. One of the things we had to deal with twice each year was that, when we switched to/from Daylight Saving Time, the java time-handling code went insane. Every time. We'd dig around to try to find the problem this time, and each time we'd find a good number of discussions of the problem.
I kept pointing them to java "standards" which stated that java's internal clock was kept in local time. I'd simply comment that this totally explains the problems. No time package whose basic clock is any representation of local time can ever be made to work quite right. The main reaction of the managers was to treat me as a trouble maker, and periodically accuse (;-) me of trying to secretly introduce Universal Time into their software, when I knew they wanted only local time.
After a few years, I moved on, as developers usually do. I've talked to the people still associated with the project off and on, and usually asked them about their DST problem. It still bites them every year. I shrug, and move on to another topic. Since then, I've worked in a few projects that used java and were contemplating changing more of the code to java. I've suggested that they should look up the twice-yearly online discussions of DST-related time bugs. This has often been enough to put a damper on further java plans.
It's good to know that the java people have a time package based on a single universal epoch counter, and which even counts nanoseconds. Maybe this will end the time problems. Or maybe managers will nix its use on the grounds that they don't want any of that UTC stuff in their code. Time will tell, I suppose.
And I suppose it's all part of the general problem of bureaucratization of the java user culture. It was pretty bad even 15 years ago, and doesn't seem to have improved with age. So I now mostly prototype in perl or python, and when I have a quick-and-dirty version running, I start talking about recoding it in java (or C++ or C or whatever). It's interesting how often I'm told to not bother, and work on a prototype for something else that's needed.
It does go along with the observation that a major reason for much our ongoing software problems is that most of our code is prototyping. Developers are rarely allowed the time to do it over the right way. I've seen cases in which N departments in a company have "standardized" on N different versions of the prototype code, all of which are slightly incompatible with the others, and none of the managers will permit redoing it all as a single package that works the same everywhere. And you have to carefully hide from them the fact that your date/time calculations use a basic UTC "epoch" counter, because they want it all to be local time.
What I find suprprising (in a way) is that Apple fans can turn a blind eye to this type of behavior while worshipping everything Apple does.
It's hardly unique to them; it's standard human behavior. I've known lots of Microsoft and IBM fans that show a similar blindness to the well-documented behavior of those companies.
Part of it seems to be based on whether people think they "chose" to buy from the company. With monopolies like the local phone and/or cable company, people can really hate them, because they have no emotional confusion caused by thinking that they "chose" the company. They know that they had no choice, and that makes the company even more evil.
But when people decide to buy a computer, they usually go to the retail outlets, see what looks like a wide range of computers, and "choose" one. They don't notice that all the machines run the same software, any more than they'd notice if two models of car have the same engine or transmission. Since they "chose" their Microsoft computer, they have an emotional entanglement based on the fact they they don't want to hear that they made a bad choice. In business surroundings, you get the same process, except that the purchase process allows them to only "choose" between computers with the IBM logo, and they don't want to think they made a bad decision, so they emotionally support IBM. (If they know that Microsoft supplied the software, that gives them an emotional tie to Microsoft, too, of course.)
The Apple fandom is a bit more sophisticated, because those people are aware that there's more than one brand of computer software. They know of two, and they consciously chose the better one. This produces the same "I don't want to look like a fool" emotional reaction when faced with criticisms of the company. Most of them are unaware of any kind of computer, because they've never seen any ads for them. But the "fanboy" reaction doesn't require comparing Apple products with other computers; it's triggered by any criticism that makes Apple look evil.
Of course, technical people tend to be aware that there are many more kinds of computer systems (and auto engines and transmissions), so they don't as often fall for this marketing trick. But they're a tiny fraction of the customer population, so the big companies don't worry about catering to them.
Some systems are properly a monopoly. The nation shouldn't have two Army services.
Ah, but here in the US, we have more than one. There's also that other one called the Marine Corps. And there's the one that used to be called Blackwater USA, then Blackwater Worldwide, and then recently renamed itself to Xe Services LLC so as to hide from all the bad publicity. I'll leave it open for other readers here to name a few of the other US Armies.
[News] like this is bringing Apple closer to the level of Sony in my mind.
It's nothing very new. For another story similar to the Apple Records story, ask google about Mark Newton and his newton.com domain, and what Apple did to him to get control of his domain name. (This can be easily tested with your browser; just type "newton.com" into the address bar, hit Return, and see where it takes you.) Apple was already using newton.apple.com, which you'd think would have been the reasonable domain name for one of their products. But they had to have newton.com, too, even though they never actually used it for much of anything.
Seriously guys, use the Internet for getting diagnostic data back but for the love of god do not hook in any control systems.
I'd guess this will work about as well as with the electronic voting boxes in recent elections. Some of the stories here talked about the discovery that some of those boxes, when visibly "disconnected", still had a live IR port. There were demos of bringing a similarly-equipped laptop into the voting area, connecting via IR to those voting machines, and poking around inside them from across the room.
Consider how people assured us that with the electronic voting stuff, they took security very seriously. But it was just "security theater", designed to impress management, the media and the computer-illiterate masses. We can expect the same thing with the security in the electric system.
Disconnect those systems from the internet and make sure the networks they connect to are not connected to the internet.
Unfortunately, most of today's management will interpret this as a physical, wired connection. We see that in some of the replies already, which assure us that an "air gap" is a solution.
But this computer I'm typing on has no wires connecting it to anything, and it's on the Internet. I could have pulled my "smart phone" out of my pocket and typed this reply on it. The days in which an air gap provided security are now completely over, and anyone who uses such a phrase merely exposes their ignorance.
And we're rapidly reaching the stage where nearly everything has a wireless connection to the Internet. If you have a new car, there's a good chance that it is permanently connected wirelessly, even if a large percentage of the owners don't realize this. There are a number of cameras that have wifi and/or GSM capability. And so on, with smaller and smaller devices as the months go by.
Getting this across to the current generation of management is going to be a problem.
Seems to me that the common sense approach is to invest heavily in technology to fix the problem, not invest heavily in public relations aimed at extending the problem. That way, we all win no matter what the truth is.
That's almost true, but there's an important caveat: There's a small population of humans that are profiting from the current economic/industrial activities that are pushing the climate towards warming. Those people generally believe they will lose if the controls on their polluting activities are curtailed. Unfortunately for the rest of us, those people tend to be extremely wealthy, and have the means to fund PR campaigns, bribe legislators, etc., to ensure that their personal short-term economic interests aren't threatened.
There's a long history showing that our industrial leaders don't, and never have, cared at all for the welfare of their workers. Workers are disposable cogs in the machinery. If their working environment results in poor health and an early death, the industrial leaders historically haven't cared at all, because there has always been a plentiful supply of young, healthy workers looking for jobs.
This story isn't a scientific issue at all. Scientists tend to react to such things in a manner exemplified by the "cold fusion" story. Their initial reaction was "Well, that's really interesting. Let's start up a bunch of independent studies to replicate the results." Those studies all failed to replicate the results, so scientists just shrugged, and went about their lives studying other things.
Most scientists have reacted to the kerfuffle over "global warming" pretty much the same way. In this case, of course, the independent studies have all pretty much pointed in the same direction. So the scientific consensus, achieved without much fuss several decades ago, is that the change is real. The remaining questions are in the details, which are slowly being worked out. One of the details, supported by quite a lot of independent studies, is that a fairly large fraction of the warming (perhaps more than 100%;-), is the result of human activity. But even here, scientists tend to react with "Well, that's interesting" and call for further studies.
Meanwhile, over in the industrial, economic, and political spheres, the reaction has been rather different. This story is about part of that. And so far, it's been mostly a lot of smoke and PR, with very little in the way of testable facts.
One things we can be fairly sure, though, is that the pressure and funding for the anti-global warming (AGW?;-) campaign gets a good deal of support from the small fraction of the population who believe they'll lose if the process is curtailed. And we're talking about people who are threatened with the loss of many millions of dollars of annual bonus money. So we can expect the pseudo-debate to continue indefinitely.
(And here in New England, we'll continue to hear the running jokes about all the people in New Hampshire and Maine who thing that global warming sounds like a fine idea. I've heard similar jokes in French from the Québecois folks further north.;-)
Unfortunately the only sure way to know how well it will work or not is to try it and see what happens.
Probably, and of course the open nature of the Internet means that people are free to experiment with a network OS. Actually, I've done that myself. Some 25 years ago, I demoed a "distributed POSIX" library that allowed me to do things like type "make" on one machine, and watch as it spun off subprocesses that compiled source on N other machines, linked them with libraries on other machines, and installed the object files into directories on yet other machines. My "netclib.a" included handling clock skew, so that the timestamps on different machines were adjusted to make them all UTC, so that make's standard scheme worked correctly. I even included a few VMS systems as some sort of show of virtuosity.
Meanwhile a guy down the hall from me was doing his own distributed unix system, and we compared notes a lot. He borrowed my clock-correction code; I borrowed several chunks of his code. Of course, the Newcastle Connection folks were there several years before us. And none of these projects has had any influence that I can detect on the current "Internet OS" movement. The new distributed OS probably won't be based on any lessons learned by those who did it decades ago.;-)
One of the predictions I'd make now might be a bit worrying. If you remember the kerfuffle a few years back, when msn.com was caught red-handed using images from customers' email and web sites in ads, you'll know where I'm headed. The first defense of msn.com was to point to the fine print of their contract, where it stated that any files stored on their computers became the legal property of msn.com. They backed off after a bit of publicity, as the parents of the kids in those ads started picking up torches and pitchforks. But the issue is still there lurking in the background. Many ISPs and web "hosting" sites still have such language in their fine print. This is going to bite a lot of people who move their stuff onto "the cloud".
Last weekend, my wife and I visited a friend who was one of the artist vendors at the Boston Flower Show. Her (the friend's) specialty is high-quality botanical drawings. Part of her income comes from making technical illustrations for botanical publications. She also sells prints of her drawings in various forms (cards, bookmarks, whatever), which she was selling at the show. The topic of putting her stuff online came up, so I described the msn.com story, and mentioned that this was a growing problem for people like musicians who want to distribute via the Internet rather than the ripoff that is the commercial music industry. A number of bands have found that their MP3s were now owned by their ISP that so graciously provided web space to customers. I made the point that if your web site is on a machine owned by any company, you may have legally handed your copyrights over to that company. Unless you're an expert "IP" lawyer, you probably won't know until it's too late. You'll find that the "hosting" company is selling your stuff, and there's nothing you can do about it.
She was visibly shocked by this. My advice was to learn to run her own web site. She uses Macs, so it's actually fairly easy. I may spend some time teaching her the basics. But she's obviously also worried about the complexity of all this. So maybe I'll end up volunteering to host her site on my machine, and promise that she keeps all the copyrights for her stuff. I've done this for a few friends who have heard the horror stories, done a bit of research, found out that I wasn't kidding, and asked for help.
Personal control was what caused the desktop-computer explosion in the 1980s, to end the control that company MIS/IT/whatever departments had over what people were allowed to do on their computers. Personal control over "IP" rights may well be what blocks widespread adoption of "cloud computing" or "Internet OS" or whatever the next buzz phrase will be. Once people re
... but how often does slashdot go down these days?
Actually, that's a good way to phrase it. That is, it may be true that slashdot itself is almost always up and running. But from my viewpoint, out here on an internet "leaf" node, slashdot quite often seems to be "down". It's fairly common that when I do a refresh, it can take a minute or more to complete. Sometimes when the "Done" appears at the bottom left of the window, the window is mostly blank, and it takes another refresh to get the summaries back on the screen.
The basic problem with the cloud-computing model is the same as with the thin-client+server model and the terminal-cluster+mainframe model: Your computing is done on one or more remote machines, over which you have no control, and even when that's working, the results you see on your screen depends on a comm network. That network might work well when first installed with short links. But if it's successful, it'll quickly become overloaded and upgraded at team of managers and workers who mostly don't have a clue about how the technical details of the system.
The bean counters can explain all they like about how much cheaper centrally-controlled computing systems are. But if you actually want to get your work done, you'll once again discover that you need a computer that can do the work locally. If you don't have control over the machine, it won't do your work the way you want it done, and the people who do control it won't have a strong motive to help you with problems that they don't see or understand.
So, having said that, does anyone know if there is a good way to resolve EXISTING duplicate files on Linux using hard links?
Yeah; I was a bit disappointed to find that the "dedupe" software talked about here doesn't seem to do that. The intent here seems to be to handle editing one of the "dupes" by splitting it apart into a new file, so that the others don't change. This is pretty much the opposite of what I find that I usually want.
Actually, I've written a couple of programs (in different langauges) to do linking of identical files for some time. One is about 25 years old, and arose in a project where we were having a lot of problems with software that "broke" hard links when changes were made to a file. This was shooting down our use of multiply-linked files to classify files in multiple ways by linking them into several appropriate directories. So we worked on software to hunt down the problems and fix them. Since we conceptualized the problem as "broken links", we called our operation "relinking". We coded up several algorithms to do the job, and pitted them against each other. We were a bit bemused to find that there wasn't really that much difference between them.;-) I kept a couple of them.
Anyway, I see that a few others have written similar tools. The problem finding them seems to be the different terminology that different developers have used. The "merge" term makes sense if you think about some other reasons you might want to do it.
Does anyone have any knowledge of other terms that might be used to google for such software? It might be interesting to find out how many times people have reinvented this particular wheel under different names.
... so why don't you simply prototype your apps to use a local rdbms while you wait for the dbas to port it to production?
Because that usually takes orders of magnitude longer than prototyping without the DB. I explained the reason: The DB is always under the control of the DB priesthood, and nothing can be done without their permission. Yes, I could set up my own "toy" DB, but that would be stepping on the priests' toes, thumbing my nose at them, or whatever metaphor you prefer to say that they would be highly offended by my intruding on their turf when they discovered what I'd done. It would permanently end any chance of them ever approving anything I wanted.
Instead, I agree in principle that it would be better to use the DB, but while I'm waiting for approval of that, I write a "temporary" prototype using flat files. I even include a flag in my code to switch to the DB access routines when they're finally working. Invariably, the project goes live using my prototype. I don't think I've ever actually seen a project in which the DB interface part was ever implemented fully while I was working there. I did once talk to the client several years after I'd left and learned that they had augmented my code with DB access, though my flat files were still in use for most of the task. The guys I talked to explained that the DB was just too slow for most of the task, and the folks in charge of the DB had never gotten around to making it work well.
The file and directory based system you describe sounds brittle to me.
Nah; it's the DB approach that's brittle. Data in a DB can change its format at any time, without warning, on the whim of the DB priesthood. I've seen it happen too many times to trust the DB. If you want your data access to be reliable, the team supporting the app needs to also control the data. If the data is controlled by a different department, inter-departmental politics always leads to such disasters. It's all to easy for the people in charge of the DB to shoot down the apps of people they're currently not getting along with.
Note that I'm not talking about anything technical here. Technically, there are good reasons to develop using the DB system. The problems are all due to organizational politics. Database systems have a strong tendency to become power centers that works independently of other parts of the organization. This is inevitable, due to the complex nature of DB systems, necessitating the professional "priesthood" that cares for the DB system, changes its diapers, etc. File systems can run indefinitely without the need for file-system experts on staff to keep them running, but this generally can't be done with DBs (except maybe for mySQL). So you get organizational politics and all the mess that that entails.
When it's (organizationally) possible to have a small DB entirely controlled by the team supporting the apps, and no way for a separate group of DB experts to take control of the data, then DBs will become a reasonable tool for the development side of the house. Until then, DBs will remain the bureaucratic nightmare that they are in most organizations, and developers who want to get their job done will simply ignore the DB side of the house for most of the development process.
... the syntax of PROLOG, for example, seems much simpler, more powerful, and makes more sense to me.
Yeah, wouldn't it be wonderful if instead of all the complex cruft usually needed to find the data you need in that morass, you could just write a prolog expression and let the interpreter resolve it? But when I mention this to Team Leaders, they inevitably look at me like I'm from Mars. They have no idea what prolog is or does. (And I'm actually from a planet much farther away than Mars.;-)
But when all is said and done, you can get familiar with most of SQL in a couple weeks.
True, perhaps, and I did that years ago. But that doesn't deal with the major problem with SQL: In my experience, every relational database I've ever worked with was in the grips of a set of professional RDB priests, and you didn't do anything in SQL without their blessing. If they didn't approve of what you were trying to do (typically because they couldn't be bothered to listen to you), it wouldn't get done during your lifetime.
So I've learned to cultivate them as an acolyte. I write my "prototype" to use flat files, typically small files full of name:value pairs, sometimes with the name part the file name and the value the contents, and a directory tree of multiply-linked files to classify stuff. I agree with their criticism of this, and say that I'd be happy to convert the code to use their DB when they have the time to help me get those subroutines working right. While they chew on that, I get the project working with the flat files, and get some users using it. When the priest finally face the fact that the project works without their help, they finally deign to help.
But I've never seen them actually get the SQL working to the point that it can supplant the flat files. The parts that do work are always so slow that turning on the "useDB" switch makes it too sluggish to actually use. In some cases, I can get around this by writing "pre-pass" code to extract the common data sets from the DB and write it to flat files, which the interactive software can read through quickly.
It has long seemed to me that SQL and RDBs in general are Good Ideas. But unless we can find a way to end the stranglehold of the DB priesthood in an organization, it's all sorta hopeless for a mere "developer" to even consider jumping into the mess. It's better to just develop stuff that works, and let the DB experts handle the task of porting it to the DB. That way, we developers can keep our hands clean of all the theology, and actually develop stuff that works.
Of course, this is all heresy to the True Believers...
If I and another person labor independently and unaware of each other, what moral or ethical principle can possibly support him getting a granted monopoly and I getting deprived of the fruits of my labor simply because in the culmination of years of effort, he reaches the patent office a few minutes earlier? Some
So why would you think that morality or ethics has anything to do with patents? The patent system's primary purpose is to guarantee that the person with the funding to support the largest team of lawyers gets all the income from your labor and/or clever ideas. That's the way it was centuries ago, when the concept of a patent was invented, and it's still the way it works.
Or in more specific terms: no matter how good the team developing a piece of software is and how long they have to do it, all it takes is one of them doing a single mistake and the results is not 100% secure.
And to make matters much worse, there is a widespread policy of attempting to keep software developers ignorant of the details of security issues. You see this all the time in management circles and discussions like this. People argue that the details of exploits should be kept secret. They claim that this is to prevent those evil hackers from using the information. But if this is all that's intended, then why do we hear this response when software developers ask for the details? The obvious conclusion is that the intent is to keep those developers ignorant. Then, of course, they write software with "known" holes, because the details are only "known" to a small group of people who are keeping it secret.
I recall back in the early days of the Web, when I didn't know much about how the Web really worked, and I also didn't know much about SQL. Scary stories started to appear about something called an "SQL Injection Attack". (Yes, this was a while ago.;-) I tried to learn what this meant -- and I was blocked everywhere I looked. All I could find was vague, fuzzy warnings about the phrase. But I couldn't find any actual examples or other explanations of just how such an attack actually worked. It took me several years to finally learn the details (in a newsgroup post that was soundly denounced by other readers as aiding and abetting the evil hackers;-).
At that point, I was finally able to look through my code and make sure that it wasn't vulnerable to such an attack. Of course, it was a bit late to do anything about possible vulnerabilities in code that I'd written in the past. That code was (mostly) proprietary and owned by companies that I didn't work for any more, so I was an outsider who (mostly) couldn't get access to it. Of course, I could contact the people who had the code, but there was no way to force them to take the issue seriously.
There are lots of vulnerabilities in our software, and part of the reason is the way that security information is intentionally hidden from the developers. "Check your code for vulnerabilities" is easy to say, but contains no information that a programmer can use. If we want actual secure software, the low-level details of all exploits must be made easily available to software developers. Until this happens, they'll continue to build software that contains known vulnerabilities, because the people writing the code don't know how to identify those vulnerabilities.
A fairly unknown researcher claimed there was a zero day in firefox, without giving enough details to tell where the bug is. So what happened was that somebody, who we not know if he is to be trusted, claimed there was a bug. Imagine!
Yeah; it's a good technique to know about. For example, I just wrote a little virus to infect slashdot and then get delivered to your system when you update any discussions like this. So now it's sitting there on your machine, reporting everything you do to my server. But don't worry; unlike those other irresponsible hackers, I won't tell anyone about how it works. So nobody except my clients will have access to the data that it's now collecting about you.
Slashdot Mirror
... just to set off a loud siren like an air raid siren. Thats how they do it now: simple, and everyone can hear it day or night and knows what it means.
Well, now; I wouldn't make that claim. Just a month ago, for example, I was driving around in a city about 1200 miles from home, in the middle of the day, and a loud siren went off. I had no clue as to what it might mean. It wasn't near a shore; there was no threatening weather anywhere nearby; there were no large planes flying overhead. And the few hundred people I could see, who were probably mostly locals, were obviously ignoring it. So either they didn't know either, or they knew and were ignoring it. I did stop and ask one person, who just shrugged, said something like "Dunno; it goes off every day at around this time and we all just ignore it."
A century or more back, loud bells and/or sirens were fairly commonly used to publicly announce things like the time of day. This made sense when watches were fairly expensive, and helped organize things in factories and the like. But these days, that's not common, because watches and clocks are cheap (and it's getting hard to be out of sight of one).
So it might take quite a bit of publicity to get a population aware of the meaning of a siren. It would be especially difficult in the vicinity of a good beach, where much of the population could be vacationers and tourists. And standardizing such things would be difficult in much of the world.
Instead of trying to put such powerful lasers in orbit and dealing with the nightmare of servicing them, why not do the obvious: Transmit the data to the ground, and put the warnings on a group of web sites that can be checked by anyone.
Of course, most people in the world wouldn't be routinely checking that web site, especially when it goes for weeks without any tsunami warnings at all. Just as they wouldn't be routinely going outside every few minutes to check for a light in the sky that never seems to be there. What you'd also have to do is publicize your site with the relevant emergency and news agencies. If you could supply data accurate to the minute and danger estimates for various islands and coasts, I'd expect that the emergency and news people there would be interested, and would be happy to install software that pops up warnings on their screen when their coordinates appear on your site.
That way, you'd get the information widespread in a matter of seconds, and response wouldn't depend on people noticing a little light up in the sky. And the local emergency people wouldn't consider you competition. You'd just be a good source of information that would make them look like heroes to their local population.
You might also consider things like an RSS feed, a twitter account, and so on.
As I recall, there has been some research on the use of orbiting lasers to accurately measure sea-surface height. You might want to find what's been written about the topic. A quick google search for "orbiting lasers sea-surface height" gets about 84,000 hits right now.
This may be a result of "niche" searches, but I was very surprised that Bing basically didn't work.
Actually, Microsoft's managers of the bing project have publicly discussed the reasons for their problems, and you basically nailed it. They concentrated on finding the most common search phrases, and optimizing for those. (They probably got that information from google. ;-) They've admitted that their optimizations only work for the roughly 1/3 of all requests that match their "common requests" list. For the other 2/3 of requests, which they've characterized as the "long tail", they admit that their approach fails as dismally as you've described.
Well, give them a few more years, and they'll probably announce yet another "new" search project that does a better job. Maybe it actually will. Or maybe it'll be another search site that fails for a new reason.
I suppose this failure is more excusable than the previous one, in which people quickly realized that they were returning "matches" pointing to their top advertisers rather than a page that had what you wanted. That one was also understandable, of course, and many people quickly realized that it was purely dishonest, in the sleazy-salesman fashion. Their latest failure is at least based on an attempt to handle search requests accurately and honestly; they just badly misjudged the variability of English phrasing and what this would mean to an approach that emphasized the most popular requests.
When 2/3 of our searches are classified as "niche" and not handled well, it's not surprising that people might look for something better. OTOH, this is true of pretty much everything that MS Windows does, and they still manage to get the overwhelming majority of sales despite handling nearly everyone's computing tasks so poorly that even dumb users routinely use obscenities to describe Microsoft products. But in the search arena, most users know a common verb that is the name of a good search site ...
They'll use the default. They always use the default.
[Citation needed] ;-)
I've seen claims that under 2% of Windows users are using a browser other than IE. I've also seen claims that 20% of Windows users are using Firefox. I sorta suspect both of these statistice, for what are probably obvious reasons.
Does anyone have actual reliable numbers on such things? I mean, with accurate descriptions of their methodology, rather than just asserting a number and expecting us to believe it?
I do know lots of Windows users of the sort that view "the internet" as the blue "e" logo. They typically don't know what a browser is, or that they're using one. They also generally can't name a computer builder; they tend to think that computer brands are names like "Dell" or "IBM", and don't know that Apple is the name of a computer company.
However, I also know lots of Windows users who are at least familiar with Apple, Firefox, etc. Some of them actually profess to hating Microsoft, use Windows only because their job requires it, and have a Mac at home. (My wife does her job-required Windows work at home in a virtual partition on her iMac. This upsets the Microsoft fanboys at work no end, while other workers have asked her for help getting it working on their Mac. ;-)
So my admittedly limited, unscientific survey says that "Windows users" are a varied lot. Some of them are dummies who just use whatever was installed on their "computer" (and that's all they know it is) when they bought it. Others consider themselves stuck with a crappy system but know a fair amount about making it less awful. I have little evidence of the proportions of such classes of users in the general Windows customer base.
Anyone know how to get reliable numbers, not just unsupported assertions?
It would be a very good thing if we could learn to distinguish between the academic, the artistic, and the business/engineering aspects of software. I don't know about you, but I really don't want to fly across an ocean in airliner designed by this year's latest and greatest methods, using revolutionary new materials that show great promise in some ways. Give me 747 or at least a 777...
Funny you should describe it that way, which is directly relevant to the topic at hand. I've worked on a couple of java projects were, out of curiosity, I wrote a little "Hello, world." program, and packaged it according to the project's official packaging rules. In each case, the result was a file over 50 MB in size. Sorta like using a 747 to deliver a postcard to a neighbor down the street.
Now, I'm quite aware that such monstrosities aren't the fault of java. Just like the existence of 747s doesn't negate the existence of ultra-light aircraft. But a corporation adapted to building a 747 or airbus probably wouldn't be the one you'd want to build your small aircraft. And a corporate software culture adapted to building the bureaucratic monstrosities that you see with java (or Cobol) probably isn't the software culture you want to build those apps for your slick new smart phone. (Or maybe I should say tablet, since today is the first sale of the iPad. ;-)
Unfortunately, programming languages tend to come with cultures, and depending on who you are, such a culture can be very appealing or very off-putting.
Because C is the new assembly language!
Uh, no; C was the new assembly language 35 years ago. By 30 years ago, C had pretty much conquered all, and assembly was a relic surviving in only a few highly-specialized niches.
And a major problem with C for the past 20 years has been the attempts to make it into a good high-level language. The result has mostly been to make it materially more difficult to write good assembly-level code in C, while not producing a good higher-level language.
Interesting. I noticed especially the comment:
Back in the late 1990s, I worked as a developer for a project that was mostly done in java. One of the things we had to deal with twice each year was that, when we switched to/from Daylight Saving Time, the java time-handling code went insane. Every time. We'd dig around to try to find the problem this time, and each time we'd find a good number of discussions of the problem.
I kept pointing them to java "standards" which stated that java's internal clock was kept in local time. I'd simply comment that this totally explains the problems. No time package whose basic clock is any representation of local time can ever be made to work quite right. The main reaction of the managers was to treat me as a trouble maker, and periodically accuse (;-) me of trying to secretly introduce Universal Time into their software, when I knew they wanted only local time.
After a few years, I moved on, as developers usually do. I've talked to the people still associated with the project off and on, and usually asked them about their DST problem. It still bites them every year. I shrug, and move on to another topic. Since then, I've worked in a few projects that used java and were contemplating changing more of the code to java. I've suggested that they should look up the twice-yearly online discussions of DST-related time bugs. This has often been enough to put a damper on further java plans.
It's good to know that the java people have a time package based on a single universal epoch counter, and which even counts nanoseconds. Maybe this will end the time problems. Or maybe managers will nix its use on the grounds that they don't want any of that UTC stuff in their code. Time will tell, I suppose.
And I suppose it's all part of the general problem of bureaucratization of the java user culture. It was pretty bad even 15 years ago, and doesn't seem to have improved with age. So I now mostly prototype in perl or python, and when I have a quick-and-dirty version running, I start talking about recoding it in java (or C++ or C or whatever). It's interesting how often I'm told to not bother, and work on a prototype for something else that's needed.
It does go along with the observation that a major reason for much our ongoing software problems is that most of our code is prototyping. Developers are rarely allowed the time to do it over the right way. I've seen cases in which N departments in a company have "standardized" on N different versions of the prototype code, all of which are slightly incompatible with the others, and none of the managers will permit redoing it all as a single package that works the same everywhere. And you have to carefully hide from them the fact that your date/time calculations use a basic UTC "epoch" counter, because they want it all to be local time.
What I find suprprising (in a way) is that Apple fans can turn a blind eye to this type of behavior while worshipping everything Apple does.
It's hardly unique to them; it's standard human behavior. I've known lots of Microsoft and IBM fans that show a similar blindness to the well-documented behavior of those companies.
Part of it seems to be based on whether people think they "chose" to buy from the company. With monopolies like the local phone and/or cable company, people can really hate them, because they have no emotional confusion caused by thinking that they "chose" the company. They know that they had no choice, and that makes the company even more evil.
But when people decide to buy a computer, they usually go to the retail outlets, see what looks like a wide range of computers, and "choose" one. They don't notice that all the machines run the same software, any more than they'd notice if two models of car have the same engine or transmission. Since they "chose" their Microsoft computer, they have an emotional entanglement based on the fact they they don't want to hear that they made a bad choice. In business surroundings, you get the same process, except that the purchase process allows them to only "choose" between computers with the IBM logo, and they don't want to think they made a bad decision, so they emotionally support IBM. (If they know that Microsoft supplied the software, that gives them an emotional tie to Microsoft, too, of course.)
The Apple fandom is a bit more sophisticated, because those people are aware that there's more than one brand of computer software. They know of two, and they consciously chose the better one. This produces the same "I don't want to look like a fool" emotional reaction when faced with criticisms of the company. Most of them are unaware of any kind of computer, because they've never seen any ads for them. But the "fanboy" reaction doesn't require comparing Apple products with other computers; it's triggered by any criticism that makes Apple look evil.
Of course, technical people tend to be aware that there are many more kinds of computer systems (and auto engines and transmissions), so they don't as often fall for this marketing trick. But they're a tiny fraction of the customer population, so the big companies don't worry about catering to them.
Some systems are properly a monopoly. The nation shouldn't have two Army services.
Ah, but here in the US, we have more than one. There's also that other one called the Marine Corps. And there's the one that used to be called Blackwater USA, then Blackwater Worldwide, and then recently renamed itself to Xe Services LLC so as to hide from all the bad publicity. I'll leave it open for other readers here to name a few of the other US Armies.
[News] like this is bringing Apple closer to the level of Sony in my mind.
It's nothing very new. For another story similar to the Apple Records story, ask google about Mark Newton and his newton.com domain, and what Apple did to him to get control of his domain name. (This can be easily tested with your browser; just type "newton.com" into the address bar, hit Return, and see where it takes you.) Apple was already using newton.apple.com, which you'd think would have been the reasonable domain name for one of their products. But they had to have newton.com, too, even though they never actually used it for much of anything.
Seriously guys, use the Internet for getting diagnostic data back but for the love of god do not hook in any control systems.
I'd guess this will work about as well as with the electronic voting boxes in recent elections. Some of the stories here talked about the discovery that some of those boxes, when visibly "disconnected", still had a live IR port. There were demos of bringing a similarly-equipped laptop into the voting area, connecting via IR to those voting machines, and poking around inside them from across the room.
Consider how people assured us that with the electronic voting stuff, they took security very seriously. But it was just "security theater", designed to impress management, the media and the computer-illiterate masses. We can expect the same thing with the security in the electric system.
It'll probably be run by the TSA.
Disconnect those systems from the internet and make sure the networks they connect to are not connected to the internet.
Unfortunately, most of today's management will interpret this as a physical, wired connection. We see that in some of the replies already, which assure us that an "air gap" is a solution.
But this computer I'm typing on has no wires connecting it to anything, and it's on the Internet. I could have pulled my "smart phone" out of my pocket and typed this reply on it. The days in which an air gap provided security are now completely over, and anyone who uses such a phrase merely exposes their ignorance.
And we're rapidly reaching the stage where nearly everything has a wireless connection to the Internet. If you have a new car, there's a good chance that it is permanently connected wirelessly, even if a large percentage of the owners don't realize this. There are a number of cameras that have wifi and/or GSM capability. And so on, with smaller and smaller devices as the months go by.
Getting this across to the current generation of management is going to be a problem.
Yeah, and I can remember thinking "How boring; I can think of several funnier replies" when I read that one.
I support web sites that force both hands to be doing something.
Hey, I can always find something to do with my other hand. ...
Huh? No; I meant I can pick up my cup of coffee and take a drink. Why did you think I meant something else?
Well, "sudo make me a sandwich" works only in the minimal sense of replying "Okay."
I'd have been more impressed if it replied "Okay, you're a sandwich."
Seems to me that the common sense approach is to invest heavily in technology to fix the problem, not invest heavily in public relations aimed at extending the problem. That way, we all win no matter what the truth is.
That's almost true, but there's an important caveat: There's a small population of humans that are profiting from the current economic/industrial activities that are pushing the climate towards warming. Those people generally believe they will lose if the controls on their polluting activities are curtailed. Unfortunately for the rest of us, those people tend to be extremely wealthy, and have the means to fund PR campaigns, bribe legislators, etc., to ensure that their personal short-term economic interests aren't threatened.
There's a long history showing that our industrial leaders don't, and never have, cared at all for the welfare of their workers. Workers are disposable cogs in the machinery. If their working environment results in poor health and an early death, the industrial leaders historically haven't cared at all, because there has always been a plentiful supply of young, healthy workers looking for jobs.
This story isn't a scientific issue at all. Scientists tend to react to such things in a manner exemplified by the "cold fusion" story. Their initial reaction was "Well, that's really interesting. Let's start up a bunch of independent studies to replicate the results." Those studies all failed to replicate the results, so scientists just shrugged, and went about their lives studying other things.
Most scientists have reacted to the kerfuffle over "global warming" pretty much the same way. In this case, of course, the independent studies have all pretty much pointed in the same direction. So the scientific consensus, achieved without much fuss several decades ago, is that the change is real. The remaining questions are in the details, which are slowly being worked out. One of the details, supported by quite a lot of independent studies, is that a fairly large fraction of the warming (perhaps more than 100% ;-), is the result of human activity. But even here, scientists tend to react with "Well, that's interesting" and call for further studies.
Meanwhile, over in the industrial, economic, and political spheres, the reaction has been rather different. This story is about part of that. And so far, it's been mostly a lot of smoke and PR, with very little in the way of testable facts.
One things we can be fairly sure, though, is that the pressure and funding for the anti-global warming (AGW? ;-) campaign gets a good deal of support from the small fraction of the population who believe they'll lose if the process is curtailed. And we're talking about people who are threatened with the loss of many millions of dollars of annual bonus money. So we can expect the pseudo-debate to continue indefinitely.
(And here in New England, we'll continue to hear the running jokes about all the people in New Hampshire and Maine who thing that global warming sounds like a fine idea. I've heard similar jokes in French from the Québecois folks further north. ;-)
Unfortunately the only sure way to know how well it will work or not is to try it and see what happens.
Probably, and of course the open nature of the Internet means that people are free to experiment with a network OS. Actually, I've done that myself. Some 25 years ago, I demoed a "distributed POSIX" library that allowed me to do things like type "make" on one machine, and watch as it spun off subprocesses that compiled source on N other machines, linked them with libraries on other machines, and installed the object files into directories on yet other machines. My "netclib.a" included handling clock skew, so that the timestamps on different machines were adjusted to make them all UTC, so that make's standard scheme worked correctly. I even included a few VMS systems as some sort of show of virtuosity.
Meanwhile a guy down the hall from me was doing his own distributed unix system, and we compared notes a lot. He borrowed my clock-correction code; I borrowed several chunks of his code. Of course, the Newcastle Connection folks were there several years before us. And none of these projects has had any influence that I can detect on the current "Internet OS" movement. The new distributed OS probably won't be based on any lessons learned by those who did it decades ago. ;-)
One of the predictions I'd make now might be a bit worrying. If you remember the kerfuffle a few years back, when msn.com was caught red-handed using images from customers' email and web sites in ads, you'll know where I'm headed. The first defense of msn.com was to point to the fine print of their contract, where it stated that any files stored on their computers became the legal property of msn.com. They backed off after a bit of publicity, as the parents of the kids in those ads started picking up torches and pitchforks. But the issue is still there lurking in the background. Many ISPs and web "hosting" sites still have such language in their fine print. This is going to bite a lot of people who move their stuff onto "the cloud".
Last weekend, my wife and I visited a friend who was one of the artist vendors at the Boston Flower Show. Her (the friend's) specialty is high-quality botanical drawings. Part of her income comes from making technical illustrations for botanical publications. She also sells prints of her drawings in various forms (cards, bookmarks, whatever), which she was selling at the show. The topic of putting her stuff online came up, so I described the msn.com story, and mentioned that this was a growing problem for people like musicians who want to distribute via the Internet rather than the ripoff that is the commercial music industry. A number of bands have found that their MP3s were now owned by their ISP that so graciously provided web space to customers. I made the point that if your web site is on a machine owned by any company, you may have legally handed your copyrights over to that company. Unless you're an expert "IP" lawyer, you probably won't know until it's too late. You'll find that the "hosting" company is selling your stuff, and there's nothing you can do about it.
She was visibly shocked by this. My advice was to learn to run her own web site. She uses Macs, so it's actually fairly easy. I may spend some time teaching her the basics. But she's obviously also worried about the complexity of all this. So maybe I'll end up volunteering to host her site on my machine, and promise that she keeps all the copyrights for her stuff. I've done this for a few friends who have heard the horror stories, done a bit of research, found out that I wasn't kidding, and asked for help.
Personal control was what caused the desktop-computer explosion in the 1980s, to end the control that company MIS/IT/whatever departments had over what people were allowed to do on their computers. Personal control over "IP" rights may well be what blocks widespread adoption of "cloud computing" or "Internet OS" or whatever the next buzz phrase will be. Once people re
... but how often does slashdot go down these days?
Actually, that's a good way to phrase it. That is, it may be true that slashdot itself is almost always up and running. But from my viewpoint, out here on an internet "leaf" node, slashdot quite often seems to be "down". It's fairly common that when I do a refresh, it can take a minute or more to complete. Sometimes when the "Done" appears at the bottom left of the window, the window is mostly blank, and it takes another refresh to get the summaries back on the screen.
The basic problem with the cloud-computing model is the same as with the thin-client+server model and the terminal-cluster+mainframe model: Your computing is done on one or more remote machines, over which you have no control, and even when that's working, the results you see on your screen depends on a comm network. That network might work well when first installed with short links. But if it's successful, it'll quickly become overloaded and upgraded at team of managers and workers who mostly don't have a clue about how the technical details of the system.
The bean counters can explain all they like about how much cheaper centrally-controlled computing systems are. But if you actually want to get your work done, you'll once again discover that you need a computer that can do the work locally. If you don't have control over the machine, it won't do your work the way you want it done, and the people who do control it won't have a strong motive to help you with problems that they don't see or understand.
So, having said that, does anyone know if there is a good way to resolve EXISTING duplicate files on Linux using hard links?
Yeah; I was a bit disappointed to find that the "dedupe" software talked about here doesn't seem to do that. The intent here seems to be to handle editing one of the "dupes" by splitting it apart into a new file, so that the others don't change. This is pretty much the opposite of what I find that I usually want.
Actually, I've written a couple of programs (in different langauges) to do linking of identical files for some time. One is about 25 years old, and arose in a project where we were having a lot of problems with software that "broke" hard links when changes were made to a file. This was shooting down our use of multiply-linked files to classify files in multiple ways by linking them into several appropriate directories. So we worked on software to hunt down the problems and fix them. Since we conceptualized the problem as "broken links", we called our operation "relinking". We coded up several algorithms to do the job, and pitted them against each other. We were a bit bemused to find that there wasn't really that much difference between them. ;-) I kept a couple of them.
Anyway, I see that a few others have written similar tools. The problem finding them seems to be the different terminology that different developers have used. The "merge" term makes sense if you think about some other reasons you might want to do it.
Does anyone have any knowledge of other terms that might be used to google for such software? It might be interesting to find out how many times people have reinvented this particular wheel under different names.
... so why don't you simply prototype your apps to use a local rdbms while you wait for the dbas to port it to production?
Because that usually takes orders of magnitude longer than prototyping without the DB. I explained the reason: The DB is always under the control of the DB priesthood, and nothing can be done without their permission. Yes, I could set up my own "toy" DB, but that would be stepping on the priests' toes, thumbing my nose at them, or whatever metaphor you prefer to say that they would be highly offended by my intruding on their turf when they discovered what I'd done. It would permanently end any chance of them ever approving anything I wanted.
Instead, I agree in principle that it would be better to use the DB, but while I'm waiting for approval of that, I write a "temporary" prototype using flat files. I even include a flag in my code to switch to the DB access routines when they're finally working. Invariably, the project goes live using my prototype. I don't think I've ever actually seen a project in which the DB interface part was ever implemented fully while I was working there. I did once talk to the client several years after I'd left and learned that they had augmented my code with DB access, though my flat files were still in use for most of the task. The guys I talked to explained that the DB was just too slow for most of the task, and the folks in charge of the DB had never gotten around to making it work well.
The file and directory based system you describe sounds brittle to me.
Nah; it's the DB approach that's brittle. Data in a DB can change its format at any time, without warning, on the whim of the DB priesthood. I've seen it happen too many times to trust the DB. If you want your data access to be reliable, the team supporting the app needs to also control the data. If the data is controlled by a different department, inter-departmental politics always leads to such disasters. It's all to easy for the people in charge of the DB to shoot down the apps of people they're currently not getting along with.
Note that I'm not talking about anything technical here. Technically, there are good reasons to develop using the DB system. The problems are all due to organizational politics. Database systems have a strong tendency to become power centers that works independently of other parts of the organization. This is inevitable, due to the complex nature of DB systems, necessitating the professional "priesthood" that cares for the DB system, changes its diapers, etc. File systems can run indefinitely without the need for file-system experts on staff to keep them running, but this generally can't be done with DBs (except maybe for mySQL). So you get organizational politics and all the mess that that entails.
When it's (organizationally) possible to have a small DB entirely controlled by the team supporting the apps, and no way for a separate group of DB experts to take control of the data, then DBs will become a reasonable tool for the development side of the house. Until then, DBs will remain the bureaucratic nightmare that they are in most organizations, and developers who want to get their job done will simply ignore the DB side of the house for most of the development process.
... the syntax of PROLOG, for example, seems much simpler, more powerful, and makes more sense to me.
Yeah, wouldn't it be wonderful if instead of all the complex cruft usually needed to find the data you need in that morass, you could just write a prolog expression and let the interpreter resolve it? But when I mention this to Team Leaders, they inevitably look at me like I'm from Mars. They have no idea what prolog is or does. (And I'm actually from a planet much farther away than Mars. ;-)
But when all is said and done, you can get familiar with most of SQL in a couple weeks.
True, perhaps, and I did that years ago. But that doesn't deal with the major problem with SQL: In my experience, every relational database I've ever worked with was in the grips of a set of professional RDB priests, and you didn't do anything in SQL without their blessing. If they didn't approve of what you were trying to do (typically because they couldn't be bothered to listen to you), it wouldn't get done during your lifetime.
So I've learned to cultivate them as an acolyte. I write my "prototype" to use flat files, typically small files full of name:value pairs, sometimes with the name part the file name and the value the contents, and a directory tree of multiply-linked files to classify stuff. I agree with their criticism of this, and say that I'd be happy to convert the code to use their DB when they have the time to help me get those subroutines working right. While they chew on that, I get the project working with the flat files, and get some users using it. When the priest finally face the fact that the project works without their help, they finally deign to help.
But I've never seen them actually get the SQL working to the point that it can supplant the flat files. The parts that do work are always so slow that turning on the "useDB" switch makes it too sluggish to actually use. In some cases, I can get around this by writing "pre-pass" code to extract the common data sets from the DB and write it to flat files, which the interactive software can read through quickly.
It has long seemed to me that SQL and RDBs in general are Good Ideas. But unless we can find a way to end the stranglehold of the DB priesthood in an organization, it's all sorta hopeless for a mere "developer" to even consider jumping into the mess. It's better to just develop stuff that works, and let the DB experts handle the task of porting it to the DB. That way, we developers can keep our hands clean of all the theology, and actually develop stuff that works.
Of course, this is all heresy to the True Believers ...
If I and another person labor independently and unaware of each other, what moral or ethical principle can possibly support him getting a granted monopoly and I getting deprived of the fruits of my labor simply because in the culmination of years of effort, he reaches the patent office a few minutes earlier? Some
So why would you think that morality or ethics has anything to do with patents? The patent system's primary purpose is to guarantee that the person with the funding to support the largest team of lawyers gets all the income from your labor and/or clever ideas. That's the way it was centuries ago, when the concept of a patent was invented, and it's still the way it works.
Perhaps you should have built your building with asbestos and then you wouldn't have fire problems?
Instead, you'd be dying of lung cancer.
(I'm trying to think of a good -- i.e., bad -- analogy here ... Anyone have one?)
Or in more specific terms: no matter how good the team developing a piece of software is and how long they have to do it, all it takes is one of them doing a single mistake and the results is not 100% secure.
And to make matters much worse, there is a widespread policy of attempting to keep software developers ignorant of the details of security issues. You see this all the time in management circles and discussions like this. People argue that the details of exploits should be kept secret. They claim that this is to prevent those evil hackers from using the information. But if this is all that's intended, then why do we hear this response when software developers ask for the details? The obvious conclusion is that the intent is to keep those developers ignorant. Then, of course, they write software with "known" holes, because the details are only "known" to a small group of people who are keeping it secret.
I recall back in the early days of the Web, when I didn't know much about how the Web really worked, and I also didn't know much about SQL. Scary stories started to appear about something called an "SQL Injection Attack". (Yes, this was a while ago. ;-) I tried to learn what this meant -- and I was blocked everywhere I looked. All I could find was vague, fuzzy warnings about the phrase. But I couldn't find any actual examples or other explanations of just how such an attack actually worked. It took me several years to finally learn the details (in a newsgroup post that was soundly denounced by other readers as aiding and abetting the evil hackers ;-).
At that point, I was finally able to look through my code and make sure that it wasn't vulnerable to such an attack. Of course, it was a bit late to do anything about possible vulnerabilities in code that I'd written in the past. That code was (mostly) proprietary and owned by companies that I didn't work for any more, so I was an outsider who (mostly) couldn't get access to it. Of course, I could contact the people who had the code, but there was no way to force them to take the issue seriously.
There are lots of vulnerabilities in our software, and part of the reason is the way that security information is intentionally hidden from the developers. "Check your code for vulnerabilities" is easy to say, but contains no information that a programmer can use. If we want actual secure software, the low-level details of all exploits must be made easily available to software developers. Until this happens, they'll continue to build software that contains known vulnerabilities, because the people writing the code don't know how to identify those vulnerabilities.
A fairly unknown researcher claimed there was a zero day in firefox, without giving enough details to tell where the bug is. So what happened was that somebody, who we not know if he is to be trusted, claimed there was a bug. Imagine!
Yeah; it's a good technique to know about. For example, I just wrote a little virus to infect slashdot and then get delivered to your system when you update any discussions like this. So now it's sitting there on your machine, reporting everything you do to my server. But don't worry; unlike those other irresponsible hackers, I won't tell anyone about how it works. So nobody except my clients will have access to the data that it's now collecting about you.