It's pretty clear that there's a risk that "we're doing agile!" can be used as a justification or smokescreen when what you're really doing is blindering through and making it up as you go along.
"Making it up as you go along" seems rather attractive to me,
as long as *some* kind of compass needle is pointing towards the goal.
I'm no agile fanboy, but planning everything first and then executing The Plan -- that's not realistic.
Due to a strange quirk in the way compilers are designed, it's (MUCH) faster to build a dozen files that include every file in your project than to build thousands of files.
Once build times are down to 5 - 15 minutes you don't need distributed compiling.
But your code will be harder to understand.
You're giving up a lot of tools, like static globals in C and anonymous namespaces in C++.
Every time I have encountered painfully long compile times, the cause has been
sloppiness. Usually, the direct cause is that noone has maintained the Makefile,
so there's an untrusted heap of recursive Makefiles which only work if you do a "make clean" first.
And which don't work with Gnu make's -j flag.
Throwing hardware at such a problem would feel like running Bubble Sort on a supercomputer.
The link step is typically the most expensive anyway, so distributed compiling doesn't get you much.
What linker are you using, and how do you use it?
For Gnu ld, the work seems to be mostly file I/O. I have seen one insane linker
which took 15 minutes and 300 MB of virtual memory to link something which ended up
a few megabytes of object code, but I hope that's not typical.
Indeed, of note, the comp.c++ and the moderated equivlent are still very much alive. I'm pretty sure the USENET Oracle is still alive too. The comp.sys.hp48 group is still be the best place for questions about HP RPN calculators, etc.
Yeah.
It's random, though -- out of two topics of similar importance, one can have
very useful newsgroups and the other garbage.
It depends on whether the topic is old enough to have rooted itself pre-September,
if there is a handful of wise and gentle people around,
and so on.
And a major flamewar (sometimes caused by a single deranged individual) can destroy
a group permanently.
By the way, I think searching Usenet is missing the point.
You learn more by lurking on a few groups which interest you,
following different discussions which may not be immediately useful to you,
maybe participating, asking and answering questions...
It seems both Opera and ping in Windows interpret individual parts with leading zeros as octal. More interestingly, Opera also accepts hexadecimal.
There's a whole list of documented valid formats in the inet_addr(3) man page on my
system -- including just a 32-bit decimal number.
There are probably others too, in other implementations.
That makes constructing a regexp that validates any arbitrary IP address, and not just a valid dot-decimal, a bit more cumbersome.
And often pointless.
Just try to use the string, and accept the possibility of error...
When one of my fellow employees quit, I took the majority of his work and turned into Perl scripts. Literally. What used to take him hours each day now takes minutes...
Let's hope none of his former colleagues tells him about it:-)
Sounds similar to the octospiders featured in the Rama sequels.
Radial symmetry, amoeboid, found as fossils...
I'm more reminded of H. P. Lovecraft's At The Mountains of Madness.
Bad news for all albino, cave-dwelling penguins.
Xubuntu is a joke of a lightweight distro. It's Ubuntu with Xfce and Gnome. (yes, effectively both).
What you needed is something like a Debian install designed for it (think LXDE) or something like Ubuntu-lite. I think PCLinuxOS has an LXDE-based edition.
I never heard of LXDE, but Debian with ctwm as a window manager
(also happens to be my favorite window manager!) works fine on my
PII 200MHz 64MB machine. No need to pick exotic distros -- just don't install crap.
The machine works well for text editing, programming and image viewing.
Modern GUI web browsers are too bloated to run well on that setup, unfortunately.
No, this is the power of the market. Laptops are mostly commoditized by now, and consumers expect to purchase a laptop that will help them solve problems. Microsoft, for whom I am not an apologist, understands that to the user, a laptop is a black plastic box that users expect good things to come out of. Linux promotors still hope that users will want to tinker with the laptop, since that's what we like to do.
Too many people equate "solve problems" in this context with
"solve problems the way Microsoft wants us to".
I don't use Unix because I like tinkering -- I use it because it's the best way to do most
of the work I do. That means a command line instead of a GUI,
troff and emacs instead of MS Word,
grap, gnuplot and Perl instead of MS Excel.
I cannot, fortunately, come up with an analog for MS PowerPoint.
In that sense, someone buying a Gnome/KDE/OOo Windows-clone laptop only pleases me
because less dollars go to Microsoft.
Re:A site geared towards Linux user, to learn Open
on
OpenBSD 4.4 Released
·
· Score: 1
As long as Linux insists on shipping tedious GNU info pages instead of normal man pages, I'm NOT interested.
Show me single Linux distro which removed man.
Show me a single Linux distro which has a man page for either bash or grep, two tools you mention. For that matter, show me a single Linux distro that has documentation that is even remotely as good as OpenBSD's. OpenBSD's man pages are truly beautiful.
What universe do you come from?
Bash has a huge man page. GNU grep has a good man page. A Linux installation which doesn't have
both of them is broken.
Yes, I have seen Linux distributions (RedHat) with a sloppy attitude to man pages,
and yes, it's laughable that the GNU yes(1) manpage first lists the two trivial
command-line options and then goes on to say:
"the full documentation for yes is maintained as a Texinfo manual"
but it's never as bad as you believe. And Debian is very acceptable, possibly as
good as OpenBSD (which I've never used).
Heh. A lot of Scandinavian candy contains ammonium chloride...
I've yet to meet any non-Scandinavian that likes it, though apparently they sell they stuff in the Netherlands and Germany too.
Ammonium chloride is not even slightly like ammonia, in the same way that table salt is not even slightly like chlorine gas.
I disagree -- there is a hint of ammonia in the taste of ammonium chloride.
And no, it doesn't taste as good in pure form as when it's used as a spice in licorice candy.
But pure NaCl doesn't taste good, either.
On the other hand, I like the smell of ammonia.
I keep a small flask by my computer (24% solution), and sniff it from time to time.
... served as a wake-up call about the risk of software bugs, and it set the stage for network security...
Calling it a wake-up call would imply that people actually woke up and fixed things afterwards.
I don't think that happened. ActiveX was invented after the Morris worm. People wrote email programs that interpreted VBScript in the mail and executed it after the Morris worm.
[...]So give me a break, but I don't think anybody woke up that time.[...]
Do you think Microsoft cared what happened on the Internet and in the Unix community
in 1988? The PC and home computer people have been mostly isolated until recently,
and have repeated the same old mistakes over and over again.
It think it was a wakeup call at the time.
It showed that you could not treat things on your Internet (or UUCP) connection
as friendly by default -- you had to install fixes for at least the most obvious
and well-known sendmail and finger bugs; you could not keep semi-public guest accounts... It also showed how serious consequences an automated attach
could have.
There have been instances when the metallurgy of times past was remarkably superior in some respects to later arts. Think of Damascus steel or Chinese bell-casting. Though the general trend of technology is constant progress forward, in certain cases the ancients were able to teach us a thing or two.
The ancients?
Heck, my grandparents could have taught me a thing or two --
like
staying alive on a small farm in a temperate climate without machines or electricity... there's lots of relatively recent knowledge getting lost,
because noone bothers to write it down, or because it's hard to describe.
"Which I belive comes from the fact that then you use the transfer control protocol TCP to handle your data transfer it sends a confirmation after receiving a package, and if you upload a lot you will have less bandwidth over for such confirmation which will therefor be sent less frequently and your download speed will drop."
Would get much longer, especially if I added "at least, maybe that statement is valid for even more protocols."
Except that it's not valid. TCP typically does not send an ACK for every packet.
Let's take a simple example. Me and my team are developing against trunk, committing every few hours, and shipping weekly. How many relevant versions of the software are there?
I count 2. One's in production, and one's at the head of the trunk. The divergence between the two is at maximum, however much the team can develop in a week.
Now I branch. How many interesting versions are there? I count 3. How much divergence is there? Well, there's release to head, release to branch, and branch to head.
It's an unnatural example.
You either branch, or you hack the trunk. A team doesn't hack the trunk and then suddenly decide to branch from some point on it and hack the branch.
The way I work with branches, the head is irrelevant.
It's identical to the latest release, and my branch is in sync with it,
so the only delta I see is between the latest release and my branch.
And (the best part) everybody else working on unrelated things can happily
ignore my branch. The things it contains doesn't become relevant to them
until I merge it and make it the next release.
Then they are supposed to sync their branches with this latest release.
(Of course, letting such a branch stay active for weeks, contain
massive and/or unrelated changes or lagging behind the latest release,
that's asking for trouble. That's the only thing everyone here seems
to agree on.)
The product's name should be "Foomatic", end of story.
There has to be *some* way of identifying which version you're running though.
Your point is really: don't make the version number part of the name; do not advertise the version number.
And I agree -- you only call something "Foomatic 5.0" if you want people to compare it
to "Foomatic N", where N<5.
Please, Debian, give us a stable 4.1 now, a "mini-lenny" just to keep ourselves (for the server side at least, as I expect most of us to run lenny on the desktop) an the rest of our userbase and potential new users happy with updates popular packages.
I suspect it's too late for that. The Debian developers would have to dig up suitably
old versions (yet fresh enough!) of their packages from months back.
Also there is the domino effect: if foobar-11.0 is a package version which everyone wants,
and the foobar people decided, for 11.0 they need a bleeding edge gcc,
or Gnome/KDE whatever, Debian would have to include these bleeding edge dependencies.
That might create a cascade effect, and they'd have to bring in bleeding edge versions
of other things which depend on gcc/Gnome/KDE.... and you'd end up with 5.0.
Man, I have to disagree with you. That kind of dinosaur thinking will hold back progress. Multi-core is the future and multi-threaded apps are exactly what's needed to fully utilize its potential.
It's funny how often the pro-concurrency crowd can come up with no better arguments than:
It's the future!
All processes must be able to use 100% of my CPU power!
It doesn't match reality. Almost all processes are I/O bound, and will continue to be so unless
networks, disks and keyboards see a sudden, major speed increase.
Some people aren't happy until they have the worst of all worlds.
Oh, do all the usual Slashdot Perl-bashing moves if you want...
Perl is a big chunk of Unix sanity which you can bring with you to Windows,
and use for Unix-y tasks. Same reasons as for installing Cygwin.
I often use perl as a normal command-line tool, when grep and awk aren't good enough.
Just send everyone ODF docs instead of MS docs.
When they complain, tell them to download OO!
The thing that get lost in this Spy-vs-Spy circus is that we'd be better off without
both of them. If you send a document to me, it's probably for viewing only. Then I'd
want (in order of preference) plain text, well-formed HTML, gzipped Postscript, or PDF. Why should
I have to install a bloody office suite just to *read* something?
Microsoft Office is evil because it's under Microsoft's control,
but *more importantly* because WYSIWYG editors in general are evil.
Take the fact that you cannot put these documents under revision control in a sane way --
just that detail costs organizations I don't know *how* much in wasted time, money and
opportunities.
Ya know, there's only one way to have a non-corruptible standards committee for file formats.
Let the FSF design file formats.
And no, I'm not kidding. They know what it means to create one thing for one purpose, and have it do its job very well, but also have the results be reusable.
I heard RMS talk about open standards a few years back (Göteborg, May 2007),
and as I recall it, he wasn't very interested.
Following a standard means to explicitly allow non-free software to compete.
For whatever reason, people fail to understand python natively supports parallel installs. Furthermore, since python's preferred script magic is "#!/bin/env python", rather than, "#!/bin/python", the executing script will use the python that it finds in your path. Additionally, you can also tie python to a specific version as "python2.5". Want a different python? Change your path. A script requires a specific version of python? Change the script to require it. It's one line and trivial. It's at the top of the file, so there's no hunting even.
Changing my path is not practical. It's too broad. I'd have to write a shell script wrapper for the
application which did 'env PATH=new_python:$PATH the_real_application "$*"' or something.
And it's not just me; I'd have to communicate this to all other users of the system somehow.
And changing one line of a script is not trivial, if I'm not root.
All this may seem like minor things, but it adds up. And no other good language puts me in situations like
that.
New python releases only pose problems for the uninitiated, the ignorant, or the dumb.
Or those of us who have been around for a while, and seen innocent backwards-incompatible changes
become maintenance nightmares...
Ok, maybe not a nightmare in this case, but an inconvenience and annoyance which
will keep being inconvenient and annoying for years, until the last Python 2.x dependency
goes away.
The best way to judge this would probably be to look at what Linux distributions like Debian want to do about Python 3.0.
They ship one Python as the default (2.4 currently, for Debian) but provide others too. I bet even a change from
2.4 to 2.5 is a major migration for them.
The whole reason why people don't shut down their Linux boxes is because booting takes so long.
I don't believe that's true.
Coming back to the state where your environment is useful takes long. Booting is a tiny part
of that time, and none of the boring work.
So you mean you do not place your sources in revision control?
If your disk crashes and you lose more than a few hours' worth
of work, you are doing something wrong.
(Or the positive version of this message: congratulations!
You can go out and pick any of dozens of free tools for revision control,
understand what it's all about, and it will take away
many of your daily worries.)
You see a side benefit quickly: In order to get code into true unit tests, each module has to do something meaningful on its own.
How is this a benefit? Normally, noone cares what the module does except its intended work.
You avoid the massive stink of excessive interdependency that paralyzes much OO code. (Much of Feather's book is about how to break those dependencies in order to test code).
Excessive interdependency doesn't sound like much fun...
but neither does excessive independency.
If the application has a hard dependency, I tend to want that to be explicit in my code.
If circus clowns
aren't in my application's target group, I happily let my Bikes have two Wheels, rather than zero-or-more virtual RollingDevices
which are pulled out of a VirtualRollingDeviceAbstractFactory.
The code's intention becomes clearer that way. I prefer understandable code to testable code,
and I prefer to catch my errors with static type checking than with tests which may or
may not exist.
I do use unit tests and I often let them affect the design to some extent...
but I refuse to let them make my code less understandable.
Slashdot Mirror
"Making it up as you go along" seems rather attractive to me, as long as *some* kind of compass needle is pointing towards the goal. I'm no agile fanboy, but planning everything first and then executing The Plan -- that's not realistic.
But your code will be harder to understand. You're giving up a lot of tools, like static globals in C and anonymous namespaces in C++.
Every time I have encountered painfully long compile times, the cause has been sloppiness. Usually, the direct cause is that noone has maintained the Makefile, so there's an untrusted heap of recursive Makefiles which only work if you do a "make clean" first. And which don't work with Gnu make's -j flag.
Throwing hardware at such a problem would feel like running Bubble Sort on a supercomputer.
What linker are you using, and how do you use it? For Gnu ld, the work seems to be mostly file I/O. I have seen one insane linker which took 15 minutes and 300 MB of virtual memory to link something which ended up a few megabytes of object code, but I hope that's not typical.
Yeah. It's random, though -- out of two topics of similar importance, one can have very useful newsgroups and the other garbage. It depends on whether the topic is old enough to have rooted itself pre-September, if there is a handful of wise and gentle people around, and so on. And a major flamewar (sometimes caused by a single deranged individual) can destroy a group permanently.
By the way, I think searching Usenet is missing the point. You learn more by lurking on a few groups which interest you, following different discussions which may not be immediately useful to you, maybe participating, asking and answering questions ...
There's a whole list of documented valid formats in the inet_addr(3) man page on my system -- including just a 32-bit decimal number. There are probably others too, in other implementations.
And often pointless. Just try to use the string, and accept the possibility of error ...
Let's hope none of his former colleagues tells him about it :-)
Radial symmetry, amoeboid, found as fossils ...
I'm more reminded of H. P. Lovecraft's At The Mountains of Madness.
Bad news for all albino, cave-dwelling penguins.
I never heard of LXDE, but Debian with ctwm as a window manager (also happens to be my favorite window manager!) works fine on my PII 200MHz 64MB machine. No need to pick exotic distros -- just don't install crap.
The machine works well for text editing, programming and image viewing. Modern GUI web browsers are too bloated to run well on that setup, unfortunately.
Too many people equate "solve problems" in this context with "solve problems the way Microsoft wants us to". I don't use Unix because I like tinkering -- I use it because it's the best way to do most of the work I do. That means a command line instead of a GUI, troff and emacs instead of MS Word, grap, gnuplot and Perl instead of MS Excel. I cannot, fortunately, come up with an analog for MS PowerPoint.
In that sense, someone buying a Gnome/KDE/OOo Windows-clone laptop only pleases me because less dollars go to Microsoft.
What universe do you come from? Bash has a huge man page. GNU grep has a good man page. A Linux installation which doesn't have both of them is broken.
Yes, I have seen Linux distributions (RedHat) with a sloppy attitude to man pages, and yes, it's laughable that the GNU yes(1) manpage first lists the two trivial command-line options and then goes on to say: "the full documentation for yes is maintained as a Texinfo manual" but it's never as bad as you believe. And Debian is very acceptable, possibly as good as OpenBSD (which I've never used).
I disagree -- there is a hint of ammonia in the taste of ammonium chloride. And no, it doesn't taste as good in pure form as when it's used as a spice in licorice candy. But pure NaCl doesn't taste good, either.
On the other hand, I like the smell of ammonia. I keep a small flask by my computer (24% solution), and sniff it from time to time.
Do you think Microsoft cared what happened on the Internet and in the Unix community in 1988? The PC and home computer people have been mostly isolated until recently, and have repeated the same old mistakes over and over again.
It think it was a wakeup call at the time. It showed that you could not treat things on your Internet (or UUCP) connection as friendly by default -- you had to install fixes for at least the most obvious and well-known sendmail and finger bugs; you could not keep semi-public guest accounts ... It also showed how serious consequences an automated attach
could have.
The ancients? Heck, my grandparents could have taught me a thing or two -- like staying alive on a small farm in a temperate climate without machines or electricity ... there's lots of relatively recent knowledge getting lost,
because noone bothers to write it down, or because it's hard to describe.
Except that it's not valid. TCP typically does not send an ACK for every packet.
It's an unnatural example. You either branch, or you hack the trunk. A team doesn't hack the trunk and then suddenly decide to branch from some point on it and hack the branch.
The way I work with branches, the head is irrelevant. It's identical to the latest release, and my branch is in sync with it, so the only delta I see is between the latest release and my branch. And (the best part) everybody else working on unrelated things can happily ignore my branch. The things it contains doesn't become relevant to them until I merge it and make it the next release. Then they are supposed to sync their branches with this latest release.
(Of course, letting such a branch stay active for weeks, contain massive and/or unrelated changes or lagging behind the latest release, that's asking for trouble. That's the only thing everyone here seems to agree on.)
Sure, but you'll find very few 100-character lines in Linux. The average line is maybe ten or fifteen characters.
There has to be *some* way of identifying which version you're running though. Your point is really: don't make the version number part of the name; do not advertise the version number. And I agree -- you only call something "Foomatic 5.0" if you want people to compare it to "Foomatic N", where N<5.
I suspect it's too late for that. The Debian developers would have to dig up suitably old versions (yet fresh enough!) of their packages from months back.
Also there is the domino effect: if foobar-11.0 is a package version which everyone wants, and the foobar people decided, for 11.0 they need a bleeding edge gcc, or Gnome/KDE whatever, Debian would have to include these bleeding edge dependencies. That might create a cascade effect, and they'd have to bring in bleeding edge versions of other things which depend on gcc/Gnome/KDE. ... and you'd end up with 5.0.
(Disclaimer: I am not a Debian developer.)
It's funny how often the pro-concurrency crowd can come up with no better arguments than:
It doesn't match reality. Almost all processes are I/O bound, and will continue to be so unless networks, disks and keyboards see a sudden, major speed increase.
Oh, do all the usual Slashdot Perl-bashing moves if you want ...
Perl is a big chunk of Unix sanity which you can bring with you to Windows,
and use for Unix-y tasks. Same reasons as for installing Cygwin.
I often use perl as a normal command-line tool, when grep and awk aren't good enough.
But I admit that a Perl/Windows shop sounds odd.
The thing that get lost in this Spy-vs-Spy circus is that we'd be better off without both of them. If you send a document to me, it's probably for viewing only. Then I'd want (in order of preference) plain text, well-formed HTML, gzipped Postscript, or PDF. Why should I have to install a bloody office suite just to *read* something?
Microsoft Office is evil because it's under Microsoft's control, but *more importantly* because WYSIWYG editors in general are evil. Take the fact that you cannot put these documents under revision control in a sane way -- just that detail costs organizations I don't know *how* much in wasted time, money and opportunities.
I heard RMS talk about open standards a few years back (Göteborg, May 2007), and as I recall it, he wasn't very interested. Following a standard means to explicitly allow non-free software to compete.
Changing my path is not practical. It's too broad. I'd have to write a shell script wrapper for the application which did 'env PATH=new_python:$PATH the_real_application "$*"' or something. And it's not just me; I'd have to communicate this to all other users of the system somehow. And changing one line of a script is not trivial, if I'm not root.
All this may seem like minor things, but it adds up. And no other good language puts me in situations like that.
Or those of us who have been around for a while, and seen innocent backwards-incompatible changes become maintenance nightmares ...
Ok, maybe not a nightmare in this case, but an inconvenience and annoyance which
will keep being inconvenient and annoying for years, until the last Python 2.x dependency
goes away.
The best way to judge this would probably be to look at what Linux distributions like Debian want to do about Python 3.0. They ship one Python as the default (2.4 currently, for Debian) but provide others too. I bet even a change from 2.4 to 2.5 is a major migration for them.
I don't believe that's true. Coming back to the state where your environment is useful takes long. Booting is a tiny part of that time, and none of the boring work.
So you mean you do not place your sources in revision control? If your disk crashes and you lose more than a few hours' worth of work, you are doing something wrong.
(Or the positive version of this message: congratulations! You can go out and pick any of dozens of free tools for revision control, understand what it's all about, and it will take away many of your daily worries.)
How is this a benefit? Normally, noone cares what the module does except its intended work.
Excessive interdependency doesn't sound like much fun ...
but neither does excessive independency.
If the application has a hard dependency, I tend to want that to be explicit in my code.
If circus clowns
aren't in my application's target group, I happily let my Bikes have two Wheels, rather than zero-or-more virtual RollingDevices
which are pulled out of a VirtualRollingDeviceAbstractFactory.
The code's intention becomes clearer that way. I prefer understandable code to testable code,
and I prefer to catch my errors with static type checking than with tests which may or
may not exist.
I do use unit tests and I often let them affect the design to some extent ...
but I refuse to let them make my code less understandable.