Odds are they're doing something like using a char field to store the password which means that whitespace *may* be trimmed, so it's safer not to allow them.
"Field" as in "database field"? They have no business storing cleartext passwords in a database.
The registry is just crap and you're a moron for even bringing it up in this context.
You're just angry that I'm pointing out that linux lacks a central repository for application and kernel settings and you have to dig through
But
(Except the user-specific settings. It's unfortunate that ~/.??* doesn't cover all such settings and nothing *but* such settings. In retrospect it should have been ~/etc/ or something.)
I can make my Makefile just as simple by targeting Linux + gcc.
Want to make it work on Clang? Oh my Makefile needs to be bigger.
Want to make it work on BSD? Oh my Makefile needs to be bigger.
Want to make it work on Solaris? Oh my Makefile needs to be bigger.
Want to make it work on Windows? Oh my Makefile needs to be huge.
Autotools exist for a reason.
Yes, but it's a reason which often is not valid. I bet I can cover any modern Unix which has gcc and Gnu make with one simple Makefile. (Using the native toolchains, especially the native make, would be significantly harder.) Windows is quite a different thing, and few Unix programmers care about it. There's no decent make there by default anyway.
Clang
Software development is full of uncertainties. Testing isn't.
I'm starting to suspect you're trolling, but
Welcome to my world, where few developers (me included) have any real idea how the product is used, and it's up to test to find out. Then approximate this by designing long-term stability tests etc (fighting the limitations of the in-house environment simulators). Then run and manage these. Then when something happens, answer questions like:
Is this important to a real customer? Is it caused by the product or the test environment? Can I convince others this is a bug? Can I do anything to narrow it down, or help the developer in some other way?
There's also customer problems: a tester is often the most important person when a high-prio bug report comes in, because it's critical to find a way to reproduce the problem. (Several times we've had to hack the product, and the test tools, and the test data, and come up with new techniques to do that. That means very close cooperation between three or four disciplines.)
Overall, there's plenty of challenging work to do, it covers many areas, and you get respected for doing it. And it's work at least as full of surprises as the programming bit.
What if one is happy with one's desktop setup from last century? Mine has, more or less, looked the same since about 1998
Mine has looked the same since 1992 or so -- it's what I ran on Solaris at the university.
I still haven't understood what's the big deal with a desktop anyway. You need ways to move your windows around, a way (like a menu) to start your favorite GUI programs, and a way to logout. A way to lock the screen too if you have people around you. A clipboard, but that's built into X11. I can't come up with a lot more useful features, and yet there's all this heat generated by various desktops reinventing themselves and pissing people off.
They don't care if Debian gets mainstream acceptance, they just care about it doing the things that a handful of developers and elitists want.
That's one way of putting it
(It also happens to be the case that a lot of non-members like me use Debian, but that's as far as I can tell a side issue.)
the fact that everyone who runs debian runs the testing version just makes my point
Except not everyone does. Most machines under my control run Debian stable, because I don't want any trouble from them. I just need them to do their job.
As someone that is new to Linux I've always found Debian to be somewhat weird. I guess a lot of Debian users uses it since they are used to it.
Hard to comment on since you don't say what you find weird. It's easy to think "weird" about anything that deviated from your own favorite Unix.
But as a new Linux user, why would I use Debian when the software is so old and outdated? We're at Firefox 20 and Debian has only version 10. OK that Firefox revs every six weeks, but you get the point.
Actually I don't. Let's assume your software is on average one year old as you use Wheezy. Software kind of worked one year ago too, you know? It's not as if 2013 was a year of great breakthroughs in computing which obsoleted everything done in the 1970--2012 timespan.
And if you feel it was, perhaps you're better off running Debian testing or some other bleeding-edge distribution, and reserve time for dealing with the "bleeding" aspect of "bleeding edge".
How about "I know how to write quality code, but I'm no longer interested in spending the necessary cycles to learn every new faddish tech. that comes down the pipe"?
Yes. Also, it's demotivating to recognize the "new" stuff as a reformulation of something people tried in the 1990s and then lost interest in. It's demotivating to immediately see the inherent flaws in it.
For me it's also recognizing that we haven't used the *old* tech to its full potential yet. For example, I could spend ten years becoming a much more powerful C or C++ or Unix programmer -- even though I've done it for 15--20 years already.
I had an intern try to optimize and clean up my code on his own initiative. It was pretty irritating. It was an internal demo and I had written the code quick and simple to get the job done. It didn't need to be clean or optimal. I wanted the intern to spend his time doing better things. OTOH, if I had tasked him to clean up my code and optimize, I might have been happy with his work.
I've experienced that too. Or more generally: designing some piece of software by myself according to some principles, working on it for a while, and then guy B steps in to help -- but B can only work according to principles *he's* used to. Stress levels rise.
Worse, I've probably been guy B myself many times. When you step into a new code base it *is* hard to get used to the style and the mindset (even writing Unix C code can be done in a surprising number of ways, and it seems everyone chooses his own), and it is hard to focus on what's important (e.g. often I find the most obviously buggy, messy or suboptimal module is one which doesn't actually need fixing).
Then stop upgrading your computer. Every single iteration of a program requires you to adapt to the new way things are done in it. OS' included.
Good OSes and programs don't. The Debian machine I use today works, for the most part, like the SunOS boxes I used 20 years ago. There are gratituous changes, but they are are limited to some high-profile projects like desktop environments (well, I don't use those), the Gimp and Firefox.
If usenet was still around, I can post question like, "I'm having difficulties [...] I miss usenet, [...]
Who told you Usenet is not around? I was there an hour ago. Some groups are still pretty decent.
I just want the ability to detect a fault and then run my entire system backwards to figure out where the problem came in. Wind River Simics can do this, but it's expensive and time-consuming to get a model of your hardware unless it happens to be something they already support. It's also slow to run (as you'd expect).
Stuff from Lauterbach also gives you that. Not slow, but expensive and hard to set up, and the user interface was hell ten years ago. Still, running the state backwards from a breakpoint was a real eye opener.
It may be worth it to spend a little time thinking in peculiarities of you data that may greatly reduce scalability problems. For instance:
1.- If your data or user base can be easily partitioned
2.- If you can get away with low consistency semantics
If you can find a nice architectural design that has any of these characteristics, many bottlenecks can be removed and scaling up in the future may prove easy. In those cases, there are abundant technology solutions that you could pick up in the future.
Or perhaps this idea of his doesn't have to be centralized at all. It seems to be a knee-jerk reaction today to "N users will want my FooBar idea, therefore I need one big www.foobar.com web application which handles all of them". Might be true given the FooBar idea -- or might not.
Usenet, Git and BitTorrent are some counter-examples.
By Harry Harrison, I've read this book. It was funny, had a bit of a hitchhikers guide feel to it. Although it was written earlier.
A lot of earlier stuff had that HHGTTG feel; Robert Sheckley for example. Phil Dick's heroes often spent time arguing with grumpy household appliances, and so on
The key elements in human thinking are not numbers but labels of fuzzy sets. -- L. Zadeh
