I second this. F-Spot is terrible. Makes a total clusterfucked mess of your filing system. I've hated it for years.
Never heard of it before, but I selected it in aptitude to see.
It wanted to pull in lots of Gnome and C# crud. Uh, no thanks.
Personally, I use John Bradley's xv for photo management.
Fifteen years old, and still the best tool for the job if you just want
to look at photos. I prefer Gimp for editing, even though xv *still* has
the better sharpening tool of the two.
You don't tell them you're doing that... you just do it. It's quicker anyway. Start by cleaning up the formatting and moving stuff into headers, some righteous macros to make the code more readable, etc., as a first step in "getting familiar with the code.
And you just made it much harder to diff the code -- an invaluable debugging tool.
That might piss me off.
After all, you don't want to break something while fixing a problem. You'll probably notice some code that looks like it's either "copy-n-paste" or dead. Keep it in mind.
You'll find potential for simplifications as you go along, and you'll also probably find other bugs and stupidities, like parameters that are never used (that happens a lot as code gets modded).
No, unused parameters is the *first* thing you see, when you turn on all those
compiler warnings which your elders invariably fail to turn on.
gcc -W -Wall -pedantic -std=c89 is your friend.
Code that doesn't smell right. Signed ints that are unsigned elsewhere. Potential buffer overruns. Unsanitized unput. In-line code that really should be in a separate function call both for clarity and for re-use. Look through the bug list - if the bug (or potential bug) you found is there, great - mark it as fixed. If not, log it, then mark it as fixed. Either way, your fixed bug count goes up - and if you can show that you've fixed bugs before they're found, that's just a bonus.
That's fine in a sense, but you have to realize that when you're new you don't know what's important.
You don't know which parts are likely to change.
You don't know the actual, unwritten requirements.
You don't know the cost of an error.
You don't know if the users will come to you if you make an error, or to your
boss, or just silently suffer.
For example, the piece of code I've maintained on and off for years sucked when I got it
-- C++ as written by a C programmer forced to use C++.
Guess what? Most of it still sucks. I still get scared and angry when I read it.
But the parts *which mattered* have been improved. In this case, the few areas which are
likely to get added functionality, i.e. the areas where I have had to add functionality in the past.
As for those sucky parts, I know that they kind of work (well enough so noone has complained anyway).
I just look the other way, and trust them.
On the other hand, I *do* refactor code more than most of my coworkers.
And I know that the *real* changes which people *want* couldn't have been done quickly
and correctly if I hadn't.
But I sometimes think it's a character flaw -- a kind of territorial pissing, to make the code mine.
And I sometimes think that even though those people who came before me were complete morons,
they worked hard and they succeeded: their "sucky" code is so good that people are willing to pay
me to maintain it.
I have a degree in mathematics (with a few CS courses), and a technical diploma in Info. Systems. My IS courses had a very strong emphasis on methodologies and writing maintainable code. I've always assumed a CS degree would have the same, along with the CS theory.
Mine didn't, with some exceptions (reasoning about correctness has been useful to me).
You learned such stuff the hard way, in hobby programming or in the compiler course,
which implied writing lots and lots of C code.
If not, that explains some of the code I've seen written by some very bright people. Some of it (not all by any means) has been technically functional, but horrible maintenance-wise.
I'm not sure education would help.
It could even make it worse -- teaching the latest fashion-of-the-week
silver bullet. They focus on a lot of stupid yet buzzwordy things at my alma mater these days,
e.g. "multicore" and "model-based architecture". Oh wait, maybe "multicore" was *last* year...
Is it just, me, or does anyone else have an issue with the name "David Dagon"?
I keep imagining the interview taking place with him sitting on a giant basalt throne
off the New England coast, at low tide...
You're surfing the net from a Commodore Amiga? Isn't that 400 megahertz PPC processor kinda slow?;-)
That message got removed after Kickstart 1.3, when an Amiga had a 8MHz MC68000.
Not that it matters -- the Amiga compensated for slow hardware with fast, well-written software.
The police officers walking the sidewalks ate donuts, openly smoked cigars, and talked to everyone, including the friendly black girls hanging out on street corners. Life was fine.
Are you saying patroling police officers shouldn't talk to prostitutes?
Why not? Seems to me that's the people they *should* talk to,
to build trust, check that they are ok and so on.
Sorry, but I have no duty to treat a murderer the same way I would treat an innocent person, even if they've served their sentence. The German parliament made a poor decision to pass a law protecting a murderer from the disgust of the public.
I'd prefer not to know, so I could treat them the way I'd treat anyone.
The way I see it, that way they have the possibility to redeem themselves.
If they are hated and persecuted everywhere they go, what good are they to themselves or
to anyone else?
The primary problems with C++ are its hideous syntax, C legacy, and severe lack of standard library components.
That's an ironic statement, since the C legacy is what's giving C++ its vast library.
If there's a C library for something, there's immediately also a C++ library.
(OK, it's not a *standard* library, and you probably want to wrap it lightly to
be safer... but personally I like it when the language doesn't shove things down my throat.
Not every library designer has the same good taste as the people who do Python's library.)
All I want and all we need is Firefox, Eclipse, a terminal and Openoffice and plain and simple menus with it.
I don't understand your point... you seem to argue for simplicity and against bloat,
but then you mention Eclipse (which according to people who *like* it regularly needs *gigabytes* of RAM)
and Openoffice?
Also, think about it yourself. What does the network do? What measures can you make that describe whether it's working well? If someone were trying to improve the network, how often would they want to see those measures?
Or maybe they just want to hear him say "it works well", or "it does not work well, because...",
or "it works well now, but since we plan for FOO to happen in N months,
I think we need to do BAR pretty damn soon".
I don't know; I haven't done those kinds of things. But at some point, going into too much detail
sounds like a plea for micro-management.
Looks like this article is more about, "what DNS is becoming but I don't like." He may not like it, but that's what's happening with DNS.
Not that I particularly like it either, but then I wasn't too happy when the word 'hacker' changed to mean 'someone who breaks into your computer.' [...] Sometimes technologies are twisted in ways you don't intend or like.
So you're saying he should shut up and learn to like it?
Part of his point is, if we let it go this way, we'll lose the opportunity to do other nifty stuff.
He explicitly mentioned a conflict between lying DNS and secure DNS.
I can't see anything wrong with pointing out such things --
especially since the vast majority of Internet users would agree with him.
Noone likes to get ad-ridden crap pages when they should have gotten
a "name or service not known" error message.
Re:Open source is the coat tails that Google rides
on
How Google Uses Linux
·
· Score: 1
They take and take from open source and throw back a couple of table scraps and you people all kiss their ass for it.
300K lines of code? Yep, table scraps.
Who said they were throwing those lines back?
They don't have to, and a short look at TFA didn't make it look as if they did.
(Not that I mind -- I myself maintain such kernel code at work.)
Back in the 90's, we had a customized patch to Apache to make it forward tickets within our intranet as supplied by our (also customized) Kerberos libraries for our (also customized) build of Lynx. [...] and I was the only person who understood it because I wrote it as the SA--when it was scrapped for a "modern" and "supportable" solution that (of course) requires a dozen full-time developers and crashes all the time.
Not really bitching too much, because that platform was a product of the go-go 90's, and IT doctrine has changed for the better. No way should a product be out there with all your customer information that only one person understands.
That sounds a lot like
"build your stuff so complicated that it needs a dozen full-time developers,
because a simple solution which one guy can maintain leaves you vulnerable".
Or are you saying your patching-based solution wasn't robust?
Some people would assume that based on your description, but I don't.
Why do you think one of the discriminators in a fat binary can't be a distribution identifier, such that there are fat slices for supporting Debian, RedHat, Ubuntu, etc., all from the dame binary file?
Such a binary would be insanely large.
Debian stable on N architectures +
Debian testing on N architectures +
RedHat something on M architectures +...
It sounds as if the people who like the idea are Mac users who expect Steve Jobs
to define what a "Mac" is at any given point in time. But that's not how Linux
(or the BSDs) work.
What *about* the BSDs, anyway? Why can't *they* get a few dozen slots in this fat binary?
And MacOS, Solaris... heck, let's throw in Windows too, that's only two extra binaries
and I'm already counting hundreds.
Another thing: how would the kernel know which one to run? Should it try them all?
Or should it read/etc/debian_version,/etc/redhat-release and so on,
using various heuristics to try to guess what the user is running?
The advantage is on the typical user side. As a Mac user over two architecture transitions, I've really appreciated just being able to pull down a single executable from a site and have it "just work". Disk space is cheap and my tolerance for pointless frustration decreases steadily with age. A distribution mechanism like fat binaries makes it so the user really has to go out of their way to get it wrong
But we're discussing Linux here, not some proprietary OS.
If you want foo, you 'aptitude install foo' and it just works.
If it doesn't you build it yourself and it just works.
By the way, if you run Linux Fedora X.Y and by accident download the Extremely Fat Binary RPM
for Fedora Z.A or SuSe B.C and it fails to install, would you say that "just works"?
Wouldn't it be more accurately described as "pointless frustration"?
One really nice thing is you can install a single fat binary on a shared network drive and clients with different architectures can all run it
That helps against architecture differences, but not differences in the OS --
e.g. shared library versions.
It's more common in my experience to run e.g. Debian Lenny on some servers and Debian Etch on others,
than to be running the exact same Linux distribution on both AMD64 and... uh, *are* there other
architectures in professional use today?
At work I install stuff on shared network drives for four Linux dists/releases/architectures.
The clients know which ones to add to the $PATH.
What does that cost me, the guy who tends to be the one who installs new stuff?
Ten seconds of thought or so, a few times a month.
And really, even *that* much simpler solution
(which BTW doesn't require me to argue with grumpy kernel maintainers)
is stupid. In retrospect, it would have been better to set up a package repository and
let the clients update themselves against it (install packages from it) regularly.
But other requirements prevent that.
To be honest, I've looked at a lot of these low power systems, but almost all of them run only a single hard disk. As the main point of these servers is for file serving, it seems remiss to not have some kind of mirroring of disks. Anyone got a good solution which supports two (or more) hard drives?
Didn't Apple announce a two-disk Mac Mini the other week?
But seriously, I have never understood this need for mirroring,
except as an excuse for buying more shiny hardware.
What do you use it for? I wouldn't use it instead of backups -- no protection
against some of the worst events.
I carry little *unique* data on my tiny one-disk server -- what is there
is mostly copies from elsewhere. What I do have (a CVS repository and
fifteen years' worth of mail and Usenet messages)
I back up to my main workstation, onto *its* second disk and one or two
different removable USB disks.
I recently went through the same search, two good options show up 1) Get a mac mini. The idle power consumption is 13 watts. You get a dvd rom, intel cpu, video out if you need it etc. It costs more and the high cpu usage is 110W. Make sure to not get the older mac mini's, only the ones starting I believe last January had the low idle watt usage.
Define "older".
My PPC Mac Mini was said to draw ~18W, and it's only slightly warm to the touch.
The external power supply is warmer though -- I wonder if that's included in
the 18W, and how much money Apple spent on making it efficient.
Matter transmission (transporters). I've no beef with using transporters as a plot device, and I see why it was attractive as a way to advance the plot in a 20-minute story line; what annoys me is the total neglect of the major impacts such a technology would have on society, even on such a controlled subculture as a Star Fleet. Given the wide availability of starships and matter transmitters, what do you suppose the inevitable criminal element in a society would think to do with them? Kidnapping, art theft, bank robbery, etc, etc. would be only a few of the impacts; obsoleting most forms of transport, and even such things as outside doors, would be another (at least, as imagined by a short story I read decades ago). However, the whole Trek universe acts as though transporters were merely a fancy elevator, a situation I find rather implausible, even within the fictional context of the Trek universe. (I still enjoy the stories, but a small corner of my being still groans at the glaring oversight.)
They don't bother me one bit, but maybe that's just because I only watch ST:TOS.
You have one ship, its five-year mission, uncharted planets with mostly various odd
savages and phony rock formations on them. If they only installed one transporter room per ship, and humans
invented them, you wouldn't see them used for much more than visiting the planets.
They also seemed expensive to run and slightly dangerous to use...
Also, maybe communications with Earth were censored, so the crew doesn't get to
hear about the alarming growth in transporter criminality.
>>>Like it or not, the term "sci-fi" has evolved so that it now means a type of speculative fiction which generally involves people living in the future, and frequently involves space ships but not always.
>>>
By this reasoning Asimov and Heinlein and Clarke didn't create science fiction or sci-fi. A huge chunk of their stories were set in the present, and didn't involve spaceships at all. Therefore you definition is flawed.
He's not defining anything, he is talking about what people think, and he uses the word "generally".
I like my definition is better - science fiction without the science should not be using that label. It should be properly categorized as fantasy along with Harry Potter and Buffy and Star Wars.
Then the golden age writers you mention should go there, too.
I'm sure Heinlein, probably Asimov and maybe even Clarke knew much of their "science" was bull, but
put it in the story because it was interesting and drove the plot. But they had to pretend they
believed in it, and so did the audience. It's very visible in many of Sturgeon's
stories -- there is half a page describing why FTL travel works, then the subject never comes up
again, like it was some ritual that had to be done. And you know what? A good story is still a good story.
It doesn't make it any less serious, or more childish.
The problem with email isn't its asynchronous nature and that's not what's being declared dead here. Everyone loves that part. The problem is how its oversimplified inbox/outbox/folder/reply-to-all format overcomplicates multi-person and multi-project conversations.
That's what USENET (or rather, a company-wide news server) would be good for, if only people
were aware of it and could handle it. And if Microsoft had a Usenet client which worked.
I often wish I could see all other technical discussions in the projects I work in.
Now I know they are taking place, but over email, and I know it's mostly by accident
I end up on the Cc: list or not. And people can't quote, trim or change the subject
line properly, as the discussion shifts to another topic.
Slashdot Mirror
Never heard of it before, but I selected it in aptitude to see. It wanted to pull in lots of Gnome and C# crud. Uh, no thanks.
Personally, I use John Bradley's xv for photo management. Fifteen years old, and still the best tool for the job if you just want to look at photos. I prefer Gimp for editing, even though xv *still* has the better sharpening tool of the two.
How about Oneko?
And you just made it much harder to diff the code -- an invaluable debugging tool. That might piss me off.
No, unused parameters is the *first* thing you see, when you turn on all those compiler warnings which your elders invariably fail to turn on.
gcc -W -Wall -pedantic -std=c89 is your friend.
That's fine in a sense, but you have to realize that when you're new you don't know what's important. You don't know which parts are likely to change. You don't know the actual, unwritten requirements. You don't know the cost of an error. You don't know if the users will come to you if you make an error, or to your boss, or just silently suffer.
For example, the piece of code I've maintained on and off for years sucked when I got it -- C++ as written by a C programmer forced to use C++. Guess what? Most of it still sucks. I still get scared and angry when I read it. But the parts *which mattered* have been improved. In this case, the few areas which are likely to get added functionality, i.e. the areas where I have had to add functionality in the past. As for those sucky parts, I know that they kind of work (well enough so noone has complained anyway). I just look the other way, and trust them.
On the other hand, I *do* refactor code more than most of my coworkers. And I know that the *real* changes which people *want* couldn't have been done quickly and correctly if I hadn't. But I sometimes think it's a character flaw -- a kind of territorial pissing, to make the code mine. And I sometimes think that even though those people who came before me were complete morons, they worked hard and they succeeded: their "sucky" code is so good that people are willing to pay me to maintain it.
Mine didn't, with some exceptions (reasoning about correctness has been useful to me). You learned such stuff the hard way, in hobby programming or in the compiler course, which implied writing lots and lots of C code.
I'm not sure education would help. It could even make it worse -- teaching the latest fashion-of-the-week silver bullet. They focus on a lot of stupid yet buzzwordy things at my alma mater these days, e.g. "multicore" and "model-based architecture". Oh wait, maybe "multicore" was *last* year ...
Odd way of phrasing it -- blue-collar is about manual labor, rather than no academic training. Programmers are by definition not white-collar.
But it seems from TFA that the term was applied by a bunch of self-described "immature snobs", who most likely were drunk. Oh well ...
Is it just, me, or does anyone else have an issue with the name "David Dagon"? I keep imagining the interview taking place with him sitting on a giant basalt throne off the New England coast, at low tide ...
That message got removed after Kickstart 1.3, when an Amiga had a 8MHz MC68000. Not that it matters -- the Amiga compensated for slow hardware with fast, well-written software.
Are you saying patroling police officers shouldn't talk to prostitutes? Why not? Seems to me that's the people they *should* talk to, to build trust, check that they are ok and so on.
I'd prefer not to know, so I could treat them the way I'd treat anyone. The way I see it, that way they have the possibility to redeem themselves. If they are hated and persecuted everywhere they go, what good are they to themselves or to anyone else?
That's an ironic statement, since the C legacy is what's giving C++ its vast library. If there's a C library for something, there's immediately also a C++ library.
(OK, it's not a *standard* library, and you probably want to wrap it lightly to be safer ... but personally I like it when the language doesn't shove things down my throat.
Not every library designer has the same good taste as the people who do Python's library.)
I don't understand your point ... you seem to argue for simplicity and against bloat,
but then you mention Eclipse (which according to people who *like* it regularly needs *gigabytes* of RAM)
and Openoffice?
Or maybe they just want to hear him say "it works well", or "it does not work well, because ...",
or "it works well now, but since we plan for FOO to happen in N months,
I think we need to do BAR pretty damn soon".
I don't know; I haven't done those kinds of things. But at some point, going into too much detail sounds like a plea for micro-management.
So you're saying he should shut up and learn to like it?
Part of his point is, if we let it go this way, we'll lose the opportunity to do other nifty stuff. He explicitly mentioned a conflict between lying DNS and secure DNS. I can't see anything wrong with pointing out such things -- especially since the vast majority of Internet users would agree with him. Noone likes to get ad-ridden crap pages when they should have gotten a "name or service not known" error message.
Who said they were throwing those lines back? They don't have to, and a short look at TFA didn't make it look as if they did. (Not that I mind -- I myself maintain such kernel code at work.)
That sounds a lot like "build your stuff so complicated that it needs a dozen full-time developers, because a simple solution which one guy can maintain leaves you vulnerable". Or are you saying your patching-based solution wasn't robust? Some people would assume that based on your description, but I don't.
Such a binary would be insanely large. Debian stable on N architectures + Debian testing on N architectures + RedHat something on M architectures + ...
It sounds as if the people who like the idea are Mac users who expect Steve Jobs
to define what a "Mac" is at any given point in time. But that's not how Linux
(or the BSDs) work.
What *about* the BSDs, anyway? Why can't *they* get a few dozen slots in this fat binary? And MacOS, Solaris ... heck, let's throw in Windows too, that's only two extra binaries
and I'm already counting hundreds.
Another thing: how would the kernel know which one to run? Should it try them all? Or should it read /etc/debian_version, /etc/redhat-release and so on,
using various heuristics to try to guess what the user is running?
But we're discussing Linux here, not some proprietary OS. If you want foo, you 'aptitude install foo' and it just works. If it doesn't you build it yourself and it just works.
By the way, if you run Linux Fedora X.Y and by accident download the Extremely Fat Binary RPM for Fedora Z.A or SuSe B.C and it fails to install, would you say that "just works"? Wouldn't it be more accurately described as "pointless frustration"?
That helps against architecture differences, but not differences in the OS -- e.g. shared library versions. It's more common in my experience to run e.g. Debian Lenny on some servers and Debian Etch on others, than to be running the exact same Linux distribution on both AMD64 and ... uh, *are* there other
architectures in professional use today?
At work I install stuff on shared network drives for four Linux dists/releases/architectures. The clients know which ones to add to the $PATH. What does that cost me, the guy who tends to be the one who installs new stuff? Ten seconds of thought or so, a few times a month.
And really, even *that* much simpler solution (which BTW doesn't require me to argue with grumpy kernel maintainers) is stupid. In retrospect, it would have been better to set up a package repository and let the clients update themselves against it (install packages from it) regularly. But other requirements prevent that.
No, a worse situation. More people will become locked into a proprietary protocol, and ...
Didn't Apple announce a two-disk Mac Mini the other week?
But seriously, I have never understood this need for mirroring, except as an excuse for buying more shiny hardware. What do you use it for? I wouldn't use it instead of backups -- no protection against some of the worst events.
I carry little *unique* data on my tiny one-disk server -- what is there is mostly copies from elsewhere. What I do have (a CVS repository and fifteen years' worth of mail and Usenet messages) I back up to my main workstation, onto *its* second disk and one or two different removable USB disks.
Define "older". My PPC Mac Mini was said to draw ~18W, and it's only slightly warm to the touch. The external power supply is warmer though -- I wonder if that's included in the 18W, and how much money Apple spent on making it efficient.
So do I. It runs Linux.
(An old ppc version, running Debian. Has run constantly since early 2005, had to replace the disk once.)
They don't bother me one bit, but maybe that's just because I only watch ST:TOS. You have one ship, its five-year mission, uncharted planets with mostly various odd savages and phony rock formations on them. If they only installed one transporter room per ship, and humans invented them, you wouldn't see them used for much more than visiting the planets. They also seemed expensive to run and slightly dangerous to use ...
Also, maybe communications with Earth were censored, so the crew doesn't get to hear about the alarming growth in transporter criminality.
He's not defining anything, he is talking about what people think, and he uses the word "generally".
Then the golden age writers you mention should go there, too. I'm sure Heinlein, probably Asimov and maybe even Clarke knew much of their "science" was bull, but put it in the story because it was interesting and drove the plot. But they had to pretend they believed in it, and so did the audience. It's very visible in many of Sturgeon's stories -- there is half a page describing why FTL travel works, then the subject never comes up again, like it was some ritual that had to be done. And you know what? A good story is still a good story. It doesn't make it any less serious, or more childish.
That's what USENET (or rather, a company-wide news server) would be good for, if only people were aware of it and could handle it. And if Microsoft had a Usenet client which worked.
I often wish I could see all other technical discussions in the projects I work in. Now I know they are taking place, but over email, and I know it's mostly by accident I end up on the Cc: list or not. And people can't quote, trim or change the subject line properly, as the discussion shifts to another topic.