What's clearly coming across here is that you're an established frat-boy who knows the arcane rules and implied hierarchy already
Politeness and respect when asking favors from people who don't know you, that's arcane rules these days? Wow...
I'm with the grandparent.
People claiming "I was badly treated by an OSS project"
without even naming the project are at least as likely to have been the one who were at fault themselves.
That also goes for "I was once badly treated by a Wikipedia editor" people.
I'm guessing you're just trolling, but here are some obvious examples:
http://office.microsoft.com/en-gb/
http://www.apple.com/ipad/
http://www.adobe.com/uk/products/photoshop.html
That makes sense; when I read your first posting praising the quality of proprietary software, my reaction
was "that's funny; most proprietary software I've used sucked much worse than the free ones, had lower-quality documentation and everything".
Microsoft's flagship products are an exception (although of course they don't do what I need, at least they are coherent and polished).
I haven't used an iPad or Photoshop, but they are also among the very few flagship products which get money and talent thrown at them.
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/etc 's mass of files to do the same thing.
But/etc *is* the central repository for application and kernel settings you're talking about.
(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... isn't it just another set of $(CC), $(CFLAGS) and $(CPPFLAGS)? Although I admit I'd want a separate "./configure --use-clang" step for that rather than "make USE_CLANG=yes clean all".
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... Another is: they're making a distribution, for themselves, that they are happy with themselves. What's the problem with that?
(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.
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...
Working with colleagues with Latex is quite simple: each colleague will write the text in whatever he/she likes. The partner will send you the text document (can be text file, ODT file, Microsoft Word file) and you copy and paste the text in the Latex project, and add Latex formats for section, paragraph, footnote, etc.
Or better: each colleague will check out/clone the project from revision control, write her part of the text in whatever she likes, and commit/push the changes. Then you can touch it up, and it goes back out on review until everyone's satisfied.
You say that like the current variety of crappy ISPs don't already strip us of our privacy and funnel our internet experience through its pipes.
The ones around here don't.
They have various pathetic schemes for locking in their customers ("look! you can get this [useless branded service] from us!") but as far as I can tell most users ignore that. Everyone I know just seems to want an IP address.
On Fedora, the System Security Services Daemon (SSSD) can be configured to cache and retrieve user SSH keys so that applications and services only have to look in one location for user keys.
Huh? The only "applications and services" that have a reason to be interested in my public keys are OpenSSH and malware. And OpenSSH already knows where to find its own keys. Yet another reason to stick with Debian, I guess...
Take a look at whatever latest OS you are currently running. Is it bug and exploit free? If you think it is, then come back in a year and there likely will be a long list of vulnerabilities found during that time. And they didn't just magically appear, most of these vulnerabilities are in your OS RIGHT NOW and there is a good chance the bad guys have known about them for quite a while too.
You're not kidding. I periodically take a look at logs and network traffic on my home server and it is a constant barrage of disease-ridden hookerbots soliciting my innocent electronics. An un-patched OS doesn't stand a chance.
Sorry, but that doesn't follow. Just because someone probes you for vulnerabilities doesn't mean these vulnerabilities exist on your host. I get a lot of ssh connect attempts using imaginative user names. Does it worry me? No, I've disabled password logins. I probably get 100 times more Windows-specific breakin attempts. No worries, I don't use Windows.
I always thought of TeX as the last gasp of the RUNOFF/nroff/troff/ditroff line of document preparation; the last of the command-line oriented word processors.
No, that's groff (GNU troff) and it's still alive and well, thank you.
'markdown' also seems promising, the way it manages to keep the markup out of the way so the source is readable in its own right.
There are lots of uses for document formats which aren't tied to a vendor and which can be put under revision control for collaborative work.
At some point there was an internal study at Bell Labs after WYSIWYG word processors were beginning to be available that found most people spent 20% of their time futzing with how the document looked instead of writing
That's a behavioral/education problem, not a GUI one. You can use Word (or any other editor) to write the text first in its entirety, and then format it.
If you start from scratch, perhaps, and write a short document in one go.
The worst side of MS Word is the one you see when you edit a long-lived document with many different authors.
Perhaps education helps, but I've never met anyone who has had proper training for serious word processing.
We just decided to move to LaTeX again for all documents that customers do not have the right to edit (most of them). The alternative was Word 2010.
Reasons are [...] svn compatible, [...]
That's a rather laconic way of putting it.
Real revision control gives you a whole array of essential things, like collaborative editing, an audit trail, the ability to work on version 2 while version 1 is still being finalized...
That's why *all* binary document formats (not just MS Office) fail my personal test.
Slashdot Mirror
What's clearly coming across here is that you're an established frat-boy who knows the arcane rules and implied hierarchy already
Politeness and respect when asking favors from people who don't know you, that's arcane rules these days? Wow ...
I'm with the grandparent. People claiming "I was badly treated by an OSS project" without even naming the project are at least as likely to have been the one who were at fault themselves. That also goes for "I was once badly treated by a Wikipedia editor" people.
I'm guessing you're just trolling, but here are some obvious examples:
http://office.microsoft.com/en-gb/
http://www.apple.com/ipad/
http://www.adobe.com/uk/products/photoshop.html
That makes sense; when I read your first posting praising the quality of proprietary software, my reaction was "that's funny; most proprietary software I've used sucked much worse than the free ones, had lower-quality documentation and everything". Microsoft's flagship products are an exception (although of course they don't do what I need, at least they are coherent and polished).
I haven't used an iPad or Photoshop, but they are also among the very few flagship products which get money and talent thrown at them.
Not everyone has the talent or desire for college, and I think we as a society ought to recognize that.
You presume that college requires talent and desire and plumbing does not.
Actually, he doesn't. He's talking about "talent or desire for college".
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 /etc 's mass of files to do the same thing.
But /etc *is* the central repository for application and kernel settings you're talking about.
(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 ... isn't it just another set of $(CC), $(CFLAGS) and $(CPPFLAGS)? Although I admit I'd want a separate "./configure --use-clang" step for that rather than "make USE_CLANG=yes clean all".
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 ... Another is: they're making a distribution, for themselves, that they are happy with themselves. What's the problem with that?
(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 ...
Working with colleagues with Latex is quite simple: each colleague will write the text in whatever he/she likes. The partner will send you the text document (can be text file, ODT file, Microsoft Word file) and you copy and paste the text in the Latex project, and add Latex formats for section, paragraph, footnote, etc.
Or better: each colleague will check out/clone the project from revision control, write her part of the text in whatever she likes, and commit/push the changes. Then you can touch it up, and it goes back out on review until everyone's satisfied.
You say that like the current variety of crappy ISPs don't already strip us of our privacy and funnel our internet experience through its pipes.
The ones around here don't. They have various pathetic schemes for locking in their customers ("look! you can get this [useless branded service] from us!") but as far as I can tell most users ignore that. Everyone I know just seems to want an IP address.
On Fedora, the System Security Services Daemon (SSSD) can be configured to cache and retrieve user SSH keys so that applications and services only have to look in one location for user keys.
Huh? The only "applications and services" that have a reason to be interested in my public keys are OpenSSH and malware. And OpenSSH already knows where to find its own keys. Yet another reason to stick with Debian, I guess ...
Take a look at whatever latest OS you are currently running. Is it bug and exploit free? If you think it is, then come back in a year and there likely will be a long list of vulnerabilities found during that time. And they didn't just magically appear, most of these vulnerabilities are in your OS RIGHT NOW and there is a good chance the bad guys have known about them for quite a while too.
You're not kidding. I periodically take a look at logs and network traffic on my home server and it is a constant barrage of disease-ridden hookerbots soliciting my innocent electronics. An un-patched OS doesn't stand a chance.
Sorry, but that doesn't follow. Just because someone probes you for vulnerabilities doesn't mean these vulnerabilities exist on your host. I get a lot of ssh connect attempts using imaginative user names. Does it worry me? No, I've disabled password logins. I probably get 100 times more Windows-specific breakin attempts. No worries, I don't use Windows.
I always thought of TeX as the last gasp of the RUNOFF/nroff/troff/ditroff line of document preparation; the last of the command-line oriented word processors.
No, that's groff (GNU troff) and it's still alive and well, thank you.
'markdown' also seems promising, the way it manages to keep the markup out of the way so the source is readable in its own right. There are lots of uses for document formats which aren't tied to a vendor and which can be put under revision control for collaborative work.
At some point there was an internal study at Bell Labs after WYSIWYG word processors were beginning to be available that found most people spent 20% of their time futzing with how the document looked instead of writing
That's a behavioral/education problem, not a GUI one. You can use Word (or any other editor) to write the text first in its entirety, and then format it.
If you start from scratch, perhaps, and write a short document in one go. The worst side of MS Word is the one you see when you edit a long-lived document with many different authors. Perhaps education helps, but I've never met anyone who has had proper training for serious word processing.
We just decided to move to LaTeX again for all documents that customers do not have the right to edit (most of them). The alternative was Word 2010. Reasons are [...] svn compatible, [...]
That's a rather laconic way of putting it. Real revision control gives you a whole array of essential things, like collaborative editing, an audit trail, the ability to work on version 2 while version 1 is still being finalized ...
That's why *all* binary document formats (not just MS Office) fail my personal test.