And before you call 'BS', note that I habitually type long, involved command-lines like that (not including all the [website.name] crap Slashdot inserted). That particular one above finds all the JPEGs in the current directory, resizes them to 320x240, quantizes them to 256 colors, writes them as GIFs, and uploads them to USENET.
And that's kinda the point of the command line. There doesn't need to be one application that fills whatever baroque need you have at the moment. Instead, you can string a bunch of smaller tools together to get there.
This is getting a shade off topic, but I thought I'd share anyway: If you spend a lot of time at the command line, you should try out some different shells and different shell configurations. You're right that modern shells often expect a fair bit of precision, which can be frustrating. That said, if you spend a lot of time there, you can set things up to be rather more comfortable than the defaults.
For example, the tcsh (TENEX C Shell) and zsh both have spelling correction that you can enable. Bash (Bourne Again SHell) has smart filename completion based on commands and flags, at least as configured by Ubuntu 10.10. For example "tar zxf ab[TAB]" will only expand out files that start with "ab" and end with ".tgz" or ".tar.gz". Ubuntu also suggests what package I might need to install if I type the name of a command that isn't installed. I would be surprised if other shells and Linux distros also didn't have features like these.
And, there's aliases. You want to make UNIX work a little more like DOS? Just alias "del" to "rm", "ren" to "mv", etc. I've seen many sites where they do this by default for their users. Most modern shells let you set up as many aliases as you like. In Bourne-derived shells, you can write "shell functions", which are like aliases on steroids and allow extensive customization.
Well, the article summary acknowledges that the CLI has its uses. It just suggest that no consumer oriented product should ever require using the command line under normal use. It doesn't say "get rid of it." It says "make it completely unnecessary for the end user of a consumer product."
I love the command line. I do 90% of my computing there. But, I can totally agree with consumer devices not requiring users to issue command lines to access basic functionality. Appliances should be appliances, and consumer electronics are generally appliances.
What this seems to be an argument against is the idea that if something is doable from the command line, you can always fall back on those commands if the GUI falls short. An end users using a truly consumer-focused product should never need those escape valves, but too many products fall short. Linux scores worst here, but Windows systems make a showing too. In contrast, Apple probably could stop shipping Terminal.app tomorrow saving it as part of an XCode install.
And I think that was the point: No "normal user" should ever require the command line. It's OK for it to be there, but only administrators, developers, support personnel and people who like to hack on their own boxes should ever need the command line. I'm OK with this line of thought.
Now I want to uuencode them and post them to USENET. Does Irfanview do that? Or maybe transfer them via SCP to various webservers.
The point is that sure, you can automate certain repetitive tasks in a GUI, but it's rare that a GUI anticipates all the potential tasks that might need automation. CLI and scripting languages combined with small focused tools that can be strung together can automate many tasks that were never anticipated by the individual tools' authors.
So, in this case, Irfanview anticipated one action to automate. Does the automation extend beyond the app's borders, though?
You're probably too young to remember text adventures, then. There was quite a lot of one-ups-man-ship in the parser department to make their parsers more capable and friendly. They were still very much command-line oriented. There's very much as "request" - "response" pattern here. The fact of the matter is that the command given to Google is a line of text.
Don't say something isn't a CLI just because it has exceedingly friendly syntax will trip all over itself to try to correct your errors. Heck, they even had programming language compilers that did that 40 years ago. It was still very much a programming language. Brittleness is not a fundamental feature if CLIs; it's merely a common one.
Outside of the webbrowser, what hand-held applications do you see needing a 4GB virtual address space in a single process?
As far as "embedded RAM", just how embedded do you mean? The latest generation OMAP chips allow for "Package-on-Package" LPDDR, for example. There's plenty of phones out there today sporting 1GB RAM, and I'm sure it's a matter of time before that's in the same package or maybe on the same die as the processor if it isn't already on some devices.
(I admit ignorance of the absolute bleeding edge...)
Yeah, what's up with that, anyway? My last two Nokias (N82 and N900) were both unlocked purchases from abroad. Why haven't they marketed their good phones here?
My N82 even came with a China-specific charger and an adaptor for plugging it in here in the US. It also had Mandarin as its default language (with some add'l marks over the keys for that) and English (UK, not US) as the second option.:-) Awesome phone till it went for a spin in a toilet bowl.
I wish I could get an N950. I'm sorely tempted to break down and get an N9.
Good luck. They're developer only, and Nokia supposedly retained the ownership of the N950s it gave to developers. I know, I've gone looking several times. I want one too.
To be clear, I think mine's great also. I can't imagine what I'd replace it with, despite its quirks. I wish the N950 weren't developer only, otherwise I'd have one. But, let's face it... there's not all that many of us out there, and Nokia all but pretends we don't exist.
This is despite the fact that the N900 and Maemo 5 got rave reviews back when it launched. Rave reviews mean nothing, it seems. Actually marketing the devices properly and getting them in peoples' hands matter, regardless of the merits of the software stack. Perhaps having multiple models running the same software stack might help too.
Nokia put way too much behind S60 for way too long, and poor-boyed the N900, hoping the community would make it a viable platform. If they were going to spend that much effort on S60, it should have been on transitioning all that S60 base to the next platform so that instead of having dozens of S60 phones on the market with a single Maemo phone, it had dozens of Maemo phones that could run S60 apps also. Maemo might have had a chance at making it big. Instead, it's a curiosity, championed by geeks in-the-know, and unheard of just about everywhere else.
The latest "ditch everything and go Windows Phone" strategy looks like a bettor's last gasp at the roulette table, hoping to hit big on 00. The fact that stores practically hide the phones though rather than trying to push them heavily suggests they'd rather not play along with that desperate strategy.
Yeah, you can tell that the folks who complain about it haven't actually listened to it. But, you might guess they listen to rather more inflammatory material on the radio dial, judging by the critical thinking skills and general decorum they exhibit.
Keep reading: "...or at least an amateur." You're right, though, I chose my words poorly. There were (and are) some very skilled, talented hackers at MIT. (Look no further than HAKMEM!) Hacks are still hacks, though, clever as they may be. The TMRC hackers (perhaps the largest MIT hacker contingent I'm aware of outside the famed MIT AI lab) describe themselves thusly:
We at TMRC use the term "hacker" only in its original meaning, someone who applies ingenuity to create a clever result, called a "hack". The essence of a "hack" is that it is done quickly, and is usually inelegant. It accomplishes the desired goal without changing the design of the system it is embedded in. Despite often being at odds with the design of the larger system, a hack is generally quite clever and effective.
Back in the 70s when they had said garage, a "hack" was someone who was unskilled or at least an amateur at whatever it was they were trying to accomplish. Hackers were just dedicated hobbyists. Their Hacker's Haven was a shop for DIY shade-tree mechanics to rent space at to work on their project cars. It wasn't until sometime into the 80s that "hacker" started taking on a different meaning.
In any case, TSA and DHS didn't exist yet, they weren't yet on the air so the FCC wouldn't give two shakes. The most they might have to worry about is ending up in a Bufile at the FBI, which seems unlikely.
You missed the part where I said we can't generate our own passwords. The computer generates a list of random passwords for us, from which we have to pick one. "squirrel1", "squirrel2" etc. aren't likely to show up. We're more likely to get X7abO3Il and the like. The computer generates 40 of those, then we get to pick one.
As for writing down our passwords -- believe it or not, our IT dept's password software actually suggests we write it down as long as we put it somewhere secure, preferably on our person, such as a wallet or purse. We're just not supposed to leave it in our workarea or with our computer. Frankly, I think that's a sufficient level of security for such a thing. Hell, if someone steals my wallet, last thing I'm worried about is them finding out my "enterprise password" for my work account. And whoever stole my wallet is likely uninterested in it anyway.
Fortunately, where I work, there are only two passwords that matter -- our UNIX / Linux passwords and our "enterprise" passwords that govern Windows and all of our web applications. But, our IT overlords haven't adopted xkcd's scheme and seem unlikely to.
The rest of my passwords on the wild and wooly web are of the randomly-generated variety (13 character mixed-case alphanumeric), but I don't even bother trying to commit any of them to memory except the couple I use daily. I keep the ones I don't use daily in an encrypted file and copy-paste them into websites. If my LinkedIn password hash was among the compromised hashes, I'm not too worried -- they'll decode many other passwords before they get to mine, and the most they'll get if they get to my LI password is my LI account. With 6.5 million hashes, they'll probably reverse several hundred thousand (if not a million or more) before they decode mine. Why would they even bother once they have that many decoded passwords?
If I had to remember all those passwords, even in XKCD's suggested format, I'd need much a better memory than I already have, since I use different passwords on every site. And, I'm sure my truly randomly generated passwords have more entropy than a four or five word phrase would.
Of course, rainbow tables can give a large factor speedup, can't they? With enough storage, you might be able to get further faster, assuming unsalted passwords.
If someone trying to crack my password knows it has exactly one upper case character, I'd assume they know because they have already cracked my password.
Or, they'd just have to know something about human nature and the fact that humans tend toward lower entropy passwords. With any password guesser that's even slightly smarter than brute force, entropy matters. I remember using 'crack' back in my college days (officially sanctioned -- we were testing password security as part of a security audit), and it had rule pattern tables that it would use to guide its search space. It was very effective. The related ANLpasswd (which we also installed) did a subset of the checks that 'crack' did.
If let run long enough, 'crack' could do a full exhaustive search over the password space. (Unlikely we'd let it run that long on our SparcStation 2s, though). But, it didn't just start with aaaa and end with ZZZZZZZZ (using your spec of 4 to 8 chars mixed case as an example). It had varieties of templates for taking dictionary words and short random strings and combining them in various ways. A couple of the filters toward the beginning of the list were "single capital letter", "single digit", "single special character" (where 'special' was any non-alphanumeric byte if memory serves), and then combinations of those things.
The completely dumb brute-force cracker assumes you need to search the entire space linearly, but any smart tool will prioritize toward repeated characters, corrupted dictionary words and other such things first. Such heuristics are very effective. I therefore find the conclusion at the password cracking page that "D0g....................." is more secure than "PrXyc.N(n4k77#L!eVdAfp9" to be very flawed, as it fails to understand what 20+ year old password cracking software already understood of human nature.
Heck, where I work we're required to use machine-generated random mixed-case alphanumeric 8 character passwords. We don't get to generate our own passwords; rather, we pick passwords from a list generated by the computer. We can also hit "regenerate" as many times as necessary until we see a password we "like". I know many people visually filter this list for more "memorable" passwords. As long as an attacker has a good model of the likely filters humans employ on this otherwise random noise, the actual search space for our passwords is much, much smaller than implied by 66^8. (I know at least one former coworker in the "single capital letter" column, for example.) At least our passwords expire every 90 days / 3 months. (Windows and *nix have slightly different expiry periods, and are required to have distinct passwords. Wheee.)
I should have phrased that differently. After all, I started off my comment with: "Nearly every program uses a singleton whether they realize it or not". And, the examples you cite are great examples.
What I was really trying to get at was that unless you're writing the low level resource managers yourself (as I was), it's uncommon to need to write new classes that are explicitly singleton (along with all the trappings of adding multiple-creation avoidance, etc.). Central resource managers and the top-level object that encapsulates your program may be singletons, but it's much less common to need to write additional explicit singletons as part of your application.
Nearly every program uses a singleton whether they realize it or not: the heap, or global store, or whatever you want to call the well that 'new' and 'malloc' dip their metaphorical buckets in.
I use singletons in applications where I have either a static resource pool that I need to manage, or the application itself is statically allocated. Now, I don't use singletons much or at all on "workstation" applications.
Where I use them mostly is in embedded environments where the specific configuration of the system is largely static and can be mostly resolved at compile time. In those cases, there's very little value to blowing a bunch of cycles at startup building objects to represent the system, when I could have precomputed all that at compile time.
Example: The buffer allocation manager? DMA channel allocation manager? Singletons with static initializer arrays that I could even link in ROM if necessary. Likewise for many other resources. This has the advantage of pushing that cost off to software integration time and compile time. As I said elsewhere in a post, my code has to run more places than on a board. It also has to run in design simulations that run amazingly slow (1ms could be 8-10 hours of sim time).
They definitely have their purpose, and I prefer their encapsulation to bare globals. But, in the common situations that most people will encounter, the singleton isn't very common at all.
What if your container needs to return things to you in some particular order, like LIFO, FIFO, static priority-order, or the like? For those, the most efficient structures are usually stacks, queues, and heaps, respectively. Hashes make decent associative arrays, and if your total number of keys is relatively stable, then can perform better than RB trees, AVL trees and the like.
Hashes are no silver bullet: Hash keys take time to compute. You can get lumpy performance if your key space varies dramatically and the underlying implementation keeps changing the number of buckets for the hash. If you pick a bad hash function (or a malicious party detects your hash function and tries to break it), you can blow up to O(n^2) performance where you expected O(n).
They're good at a number of things, but they're not best at everything.
Slashdot Mirror
Who says a single command line utility need to do that? I can do it in a single command line, though.
newspost -s "More pics" -p posting.par $(for I in *.jpg ; do G=upload/${I%.jpg}.gif ; djpeg -pnm $I | pamscale -xsize 320 -ysize 240 | pnmquant 256 | ppmtogif > $G ; echo $G)
And before you call 'BS', note that I habitually type long, involved command-lines like that (not including all the [website.name] crap Slashdot inserted). That particular one above finds all the JPEGs in the current directory, resizes them to 320x240, quantizes them to 256 colors, writes them as GIFs, and uploads them to USENET.
And that's kinda the point of the command line. There doesn't need to be one application that fills whatever baroque need you have at the moment. Instead, you can string a bunch of smaller tools together to get there.
This is getting a shade off topic, but I thought I'd share anyway: If you spend a lot of time at the command line, you should try out some different shells and different shell configurations. You're right that modern shells often expect a fair bit of precision, which can be frustrating. That said, if you spend a lot of time there, you can set things up to be rather more comfortable than the defaults.
For example, the tcsh (TENEX C Shell) and zsh both have spelling correction that you can enable. Bash (Bourne Again SHell) has smart filename completion based on commands and flags, at least as configured by Ubuntu 10.10. For example "tar zxf ab[TAB]" will only expand out files that start with "ab" and end with ".tgz" or ".tar.gz". Ubuntu also suggests what package I might need to install if I type the name of a command that isn't installed. I would be surprised if other shells and Linux distros also didn't have features like these.
And, there's aliases. You want to make UNIX work a little more like DOS? Just alias "del" to "rm", "ren" to "mv", etc. I've seen many sites where they do this by default for their users. Most modern shells let you set up as many aliases as you like. In Bourne-derived shells, you can write "shell functions", which are like aliases on steroids and allow extensive customization.
Well, the article summary acknowledges that the CLI has its uses. It just suggest that no consumer oriented product should ever require using the command line under normal use. It doesn't say "get rid of it." It says "make it completely unnecessary for the end user of a consumer product."
I love the command line. I do 90% of my computing there. But, I can totally agree with consumer devices not requiring users to issue command lines to access basic functionality. Appliances should be appliances, and consumer electronics are generally appliances.
What this seems to be an argument against is the idea that if something is doable from the command line, you can always fall back on those commands if the GUI falls short. An end users using a truly consumer-focused product should never need those escape valves, but too many products fall short. Linux scores worst here, but Windows systems make a showing too. In contrast, Apple probably could stop shipping Terminal.app tomorrow saving it as part of an XCode install.
And I think that was the point: No "normal user" should ever require the command line. It's OK for it to be there, but only administrators, developers, support personnel and people who like to hack on their own boxes should ever need the command line. I'm OK with this line of thought.
Now I want to uuencode them and post them to USENET. Does Irfanview do that? Or maybe transfer them via SCP to various webservers.
The point is that sure, you can automate certain repetitive tasks in a GUI, but it's rare that a GUI anticipates all the potential tasks that might need automation. CLI and scripting languages combined with small focused tools that can be strung together can automate many tasks that were never anticipated by the individual tools' authors.
So, in this case, Irfanview anticipated one action to automate. Does the automation extend beyond the app's borders, though?
You're probably too young to remember text adventures, then. There was quite a lot of one-ups-man-ship in the parser department to make their parsers more capable and friendly. They were still very much command-line oriented. There's very much as "request" - "response" pattern here. The fact of the matter is that the command given to Google is a line of text.
Don't say something isn't a CLI just because it has exceedingly friendly syntax will trip all over itself to try to correct your errors. Heck, they even had programming language compilers that did that 40 years ago. It was still very much a programming language. Brittleness is not a fundamental feature if CLIs; it's merely a common one.
Outside of the webbrowser, what hand-held applications do you see needing a 4GB virtual address space in a single process?
As far as "embedded RAM", just how embedded do you mean? The latest generation OMAP chips allow for "Package-on-Package" LPDDR, for example. There's plenty of phones out there today sporting 1GB RAM, and I'm sure it's a matter of time before that's in the same package or maybe on the same die as the processor if it isn't already on some devices.
(I admit ignorance of the absolute bleeding edge...)
Yeah, what's up with that, anyway? My last two Nokias (N82 and N900) were both unlocked purchases from abroad. Why haven't they marketed their good phones here?
My N82 even came with a China-specific charger and an adaptor for plugging it in here in the US. It also had Mandarin as its default language (with some add'l marks over the keys for that) and English (UK, not US) as the second option. :-) Awesome phone till it went for a spin in a toilet bowl.
I wish I could get an N950. I'm sorely tempted to break down and get an N9.
N9 or N900? The two are different phones...
It's not a phone, though, is it?
Good luck. They're developer only, and Nokia supposedly retained the ownership of the N950s it gave to developers. I know, I've gone looking several times. I want one too.
To be clear, I think mine's great also. I can't imagine what I'd replace it with, despite its quirks. I wish the N950 weren't developer only, otherwise I'd have one. But, let's face it... there's not all that many of us out there, and Nokia all but pretends we don't exist.
This is despite the fact that the N900 and Maemo 5 got rave reviews back when it launched. Rave reviews mean nothing, it seems. Actually marketing the devices properly and getting them in peoples' hands matter, regardless of the merits of the software stack. Perhaps having multiple models running the same software stack might help too.
Nokia put way too much behind S60 for way too long, and poor-boyed the N900, hoping the community would make it a viable platform. If they were going to spend that much effort on S60, it should have been on transitioning all that S60 base to the next platform so that instead of having dozens of S60 phones on the market with a single Maemo phone, it had dozens of Maemo phones that could run S60 apps also. Maemo might have had a chance at making it big. Instead, it's a curiosity, championed by geeks in-the-know, and unheard of just about everywhere else.
The latest "ditch everything and go Windows Phone" strategy looks like a bettor's last gasp at the roulette table, hoping to hit big on 00. The fact that stores practically hide the phones though rather than trying to push them heavily suggests they'd rather not play along with that desperate strategy.
I'm sure there's at least some rational hate too.
So is your beef, uhm, beef then?
I remember Maemo 5 met with good reviews also. All three fellow N900 users out there, raise your hands...
This page lists the maximum operating altitude of the new MBPs as 10,000 feet. Does that mean you can't use them on airplanes? That seems silly... The only moving parts on there should be fans, right? No hard drive to crash. So why such a low service ceiling?
Yeah, you can tell that the folks who complain about it haven't actually listened to it. But, you might guess they listen to rather more inflammatory material on the radio dial, judging by the critical thinking skills and general decorum they exhibit.
Keep reading: "...or at least an amateur." You're right, though, I chose my words poorly. There were (and are) some very skilled, talented hackers at MIT. (Look no further than HAKMEM!) Hacks are still hacks, though, clever as they may be. The TMRC hackers (perhaps the largest MIT hacker contingent I'm aware of outside the famed MIT AI lab) describe themselves thusly:
Back in the 70s when they had said garage, a "hack" was someone who was unskilled or at least an amateur at whatever it was they were trying to accomplish. Hackers were just dedicated hobbyists. Their Hacker's Haven was a shop for DIY shade-tree mechanics to rent space at to work on their project cars. It wasn't until sometime into the 80s that "hacker" started taking on a different meaning.
In any case, TSA and DHS didn't exist yet, they weren't yet on the air so the FCC wouldn't give two shakes. The most they might have to worry about is ending up in a Bufile at the FBI, which seems unlikely.
You missed the part where I said we can't generate our own passwords. The computer generates a list of random passwords for us, from which we have to pick one. "squirrel1", "squirrel2" etc. aren't likely to show up. We're more likely to get X7abO3Il and the like. The computer generates 40 of those, then we get to pick one.
As for writing down our passwords -- believe it or not, our IT dept's password software actually suggests we write it down as long as we put it somewhere secure, preferably on our person, such as a wallet or purse. We're just not supposed to leave it in our workarea or with our computer. Frankly, I think that's a sufficient level of security for such a thing. Hell, if someone steals my wallet, last thing I'm worried about is them finding out my "enterprise password" for my work account. And whoever stole my wallet is likely uninterested in it anyway.
Fortunately, where I work, there are only two passwords that matter -- our UNIX / Linux passwords and our "enterprise" passwords that govern Windows and all of our web applications. But, our IT overlords haven't adopted xkcd's scheme and seem unlikely to.
The rest of my passwords on the wild and wooly web are of the randomly-generated variety (13 character mixed-case alphanumeric), but I don't even bother trying to commit any of them to memory except the couple I use daily. I keep the ones I don't use daily in an encrypted file and copy-paste them into websites. If my LinkedIn password hash was among the compromised hashes, I'm not too worried -- they'll decode many other passwords before they get to mine, and the most they'll get if they get to my LI password is my LI account. With 6.5 million hashes, they'll probably reverse several hundred thousand (if not a million or more) before they decode mine. Why would they even bother once they have that many decoded passwords?
If I had to remember all those passwords, even in XKCD's suggested format, I'd need much a better memory than I already have, since I use different passwords on every site. And, I'm sure my truly randomly generated passwords have more entropy than a four or five word phrase would.
Of course, rainbow tables can give a large factor speedup, can't they? With enough storage, you might be able to get further faster, assuming unsalted passwords.
Or, they'd just have to know something about human nature and the fact that humans tend toward lower entropy passwords. With any password guesser that's even slightly smarter than brute force, entropy matters. I remember using 'crack' back in my college days (officially sanctioned -- we were testing password security as part of a security audit), and it had rule pattern tables that it would use to guide its search space. It was very effective. The related ANLpasswd (which we also installed) did a subset of the checks that 'crack' did.
If let run long enough, 'crack' could do a full exhaustive search over the password space. (Unlikely we'd let it run that long on our SparcStation 2s, though). But, it didn't just start with aaaa and end with ZZZZZZZZ (using your spec of 4 to 8 chars mixed case as an example). It had varieties of templates for taking dictionary words and short random strings and combining them in various ways. A couple of the filters toward the beginning of the list were "single capital letter", "single digit", "single special character" (where 'special' was any non-alphanumeric byte if memory serves), and then combinations of those things.
The completely dumb brute-force cracker assumes you need to search the entire space linearly, but any smart tool will prioritize toward repeated characters, corrupted dictionary words and other such things first. Such heuristics are very effective. I therefore find the conclusion at the password cracking page that "D0g....................." is more secure than "PrXyc.N(n4k77#L!eVdAfp9" to be very flawed, as it fails to understand what 20+ year old password cracking software already understood of human nature.
Heck, where I work we're required to use machine-generated random mixed-case alphanumeric 8 character passwords. We don't get to generate our own passwords; rather, we pick passwords from a list generated by the computer. We can also hit "regenerate" as many times as necessary until we see a password we "like". I know many people visually filter this list for more "memorable" passwords. As long as an attacker has a good model of the likely filters humans employ on this otherwise random noise, the actual search space for our passwords is much, much smaller than implied by 66^8. (I know at least one former coworker in the "single capital letter" column, for example.) At least our passwords expire every 90 days / 3 months. (Windows and *nix have slightly different expiry periods, and are required to have distinct passwords. Wheee.)
I should have phrased that differently. After all, I started off my comment with: "Nearly every program uses a singleton whether they realize it or not". And, the examples you cite are great examples.
What I was really trying to get at was that unless you're writing the low level resource managers yourself (as I was), it's uncommon to need to write new classes that are explicitly singleton (along with all the trappings of adding multiple-creation avoidance, etc.). Central resource managers and the top-level object that encapsulates your program may be singletons, but it's much less common to need to write additional explicit singletons as part of your application.
Nearly every program uses a singleton whether they realize it or not: the heap, or global store, or whatever you want to call the well that 'new' and 'malloc' dip their metaphorical buckets in.
I use singletons in applications where I have either a static resource pool that I need to manage, or the application itself is statically allocated. Now, I don't use singletons much or at all on "workstation" applications.
Where I use them mostly is in embedded environments where the specific configuration of the system is largely static and can be mostly resolved at compile time. In those cases, there's very little value to blowing a bunch of cycles at startup building objects to represent the system, when I could have precomputed all that at compile time.
Example: The buffer allocation manager? DMA channel allocation manager? Singletons with static initializer arrays that I could even link in ROM if necessary. Likewise for many other resources. This has the advantage of pushing that cost off to software integration time and compile time. As I said elsewhere in a post, my code has to run more places than on a board. It also has to run in design simulations that run amazingly slow (1ms could be 8-10 hours of sim time).
They definitely have their purpose, and I prefer their encapsulation to bare globals. But, in the common situations that most people will encounter, the singleton isn't very common at all.
What if your container needs to return things to you in some particular order, like LIFO, FIFO, static priority-order, or the like? For those, the most efficient structures are usually stacks, queues, and heaps, respectively. Hashes make decent associative arrays, and if your total number of keys is relatively stable, then can perform better than RB trees, AVL trees and the like.
Hashes are no silver bullet: Hash keys take time to compute. You can get lumpy performance if your key space varies dramatically and the underlying implementation keeps changing the number of buckets for the hash. If you pick a bad hash function (or a malicious party detects your hash function and tries to break it), you can blow up to O(n^2) performance where you expected O(n).
They're good at a number of things, but they're not best at everything.