...unless you really want/need to support ancient and obscure platforms. But since the question specifically *said* modern and maintained platforms, then autoconf will just uglify and complicate your code.
And in answer to the original question: yes, if you're talking modern unix or unix-like systems (i.e. AIX 4.3 or 5, Solaris 7 or later, Linux/glibc or BSD from the last several years, HPUX 11), then yes, you can assume POSIX and C89 (although for AIX, Solaris, and HPUX you'll need to buy a compiler or install GCC).
You've completely confused patents vs. copyright. Copyrights protect the expression of an idea, and your arguments are more-or-less correct w.r.t. copyrights.
Patents exist to protect an idea. And yes, you can come up with the idea completely independently, and express it differently, but still be in violation of a patent. That's pretty much a requirement for patents to be useful. Otherwise you could just look at the patent but claim you hadn't.
I'm not sure why we couldn't have just added temp sensors to compensate...
Because the compensation factor varies with the composition, and gasoline composition varies significantly by location and season. It's the sort of thing that reasonable to deal with in refineries and petrochemical plants, less so in small, unmaintained locations.
Content plugins have fairly simple API requirements,
basically just a way to say "take this stream
of bytes, and display it here. Also, tell
me how big a rectangle you need", plus probably few
other things.
Browser extensions require knowledge and access to the internals of the specified browser, and doing
things liking hooking into calls in internal subroutines. The spec would
not only be large, but also put huge limits on
the internal implementation of the browser. Ain't going to happen.
How does the peloton know how much speed to pick up to sweep up a break away with a 12 minute lead, 10 km from the finish line?
If the breakaway is 12 minutes ahead 10km from
the line, they are not going to be caught, unless they all fall off of their bikes...
Assume the breakaway group/rider is moving at
20kph (not very fast, say it's uphill). They'll
finish in 30 minutes. The peloton 12 minutes back has
an extra 4km to go (20kph * 0.2h). That means they have to average 28kph to catch the breakaway, or 40% faster. Extremely unlikely.
(Yeah, you can slow the speeds down enough to make it work...)
That's pretty much what everyone said about McLaren 1987-90, when they were the dominant team. In '88, Senna and Prost won all the races but one. That was better, though, because you didn't which of Senna or Prost was going to win.
I like dnsmasq and use it on my small home network, but it doesn't meet the requirements of the original poster: forwarding queries to specific servers based on domain name or ip.
I realize that such a desire is fundamentally at odds with the way DNS works, but I've had many situations where such a capability would make life a lot easier.
I don't think you fully grasp the problems that the autotools actually do solve for developers.
If the autotools, did, in fact, solve the
problems, then I'd have less of an objection. But they
don't. They merely mask the problems in copious
output, unreadable logs, and bad code. Autoconf
is bad enough, but when you get the atrocious automake and libtool plastered on, it's pretty
much undecipherable.
The gtk/gnome approach of the *-config script
is a much cleaner way of dealing with optional
subsystems. Let the library itself tell you where
stuff is and how to use it, not some other thing
guessing, usually wrong.
As for "provincial", I'm going to guess you haven't done much porting between non-unixlike systems, if you think autoconf is a good thing.
It's really not that hard. The autotools are crutch for people who can't be bothered to actually learn the C language and library, or the difference between POSIX and what their current environment provides. Go read #ifdef Considered Harmful (PDF) by Henry Spencer, about the right way to deal with portability problems, and notice that the whole approach of autoconf is wrong.
"checking for stdlib.h..." indeed. If you
don't have an ISO-C environment, you're so
screwed that there's nothing autoconf can do to
save you: you don't know how the language works, so whether or not you're missing a few library
functions isn't going to make any difference.
I once worked on a fairly large process control system, of which less than 1% was portability code. It ran on Solaris, AIX, HP-UX (this was pre-Linux). It also ran on VMS and WinNT. Most of the portability issues dealt with the entirely different models for process management and memory-mapped files, not with pipsqueek stuff like
autoconf.
It's real simple: you read the docs. You determine what the standard actually requires, not what your development system happens to do. And you program to that, then test.
As for the autotools proclaimed ability to port to systems you weren't planning for, that's so much BS. If the system is sufficiently different that ANSI C and POSIX aren't sufficient, then you're going to have to update your code anyway.
Replacing autoconf with some other crutch isn't going to help. Just ditch it entirely.
3. Put all the donations in an envelope, use them honestly, and report them as income to the IRS. Then you don't have to worry.
Of course, if a years worth of donations totals $172.43, then you don't have to worry anyway. Just
pay part of your ISP bill and be happy.
There's no need to register a business, unless you are actually doing business, and accepting donations for your hobby doesn't qualify.
All of the above assumes you aren't trying to deduct the expenses of your project, of course. If you actually have enough money traveling around to make doing so worthwhile, then you should create a seperate business, with seperate accounts and everything.
Bullshit yourself. Of course you back up the SCC repository. The problem is that VSS repositories go bad without showing the signs until later. So you have nice backups of corrupt data. Woohoo! And yes, one can sometimes pick through and fix the problem. It's a lovely way to spend the day or weekend.
If you know what you're doing you should never get corrupted files or lose history or anything like that.
Absolutely correct. That should never happen. But we did know what we were doing, and it happened none-the-less. Nor is that a unique experience - Google around and you'll see plenty of experienced people who've had issues with VSS.
VSS may be adequate for a small developer group that never has to support a released product (no useful branching, remember?) and has time to babysit it. But there's nothing it does that CVS doesn't do better, and CVS is free, reliable, and a hell of a lot more capable. In the extremely unlikely event that a CVS repository does go tits up, one can fix the damn thing with a text editor (I think I've had to do this maybe once in several years of heavy CVS use).
Is CVS perfect? Of course not. But there's no reason to recommend VSS over CVS.
No, I'm not just dinging it because it's an MS product. I've used VSS extensively, and my conclusion is that you should not put anything valuable into VSS unless you have backup copies elsewhere, which sort of defeats the purpose. It's a fragile POS, breaks at glance, and provides no functionatility that is not better implemented elsewhere and more cheaply. If you're willing to
pay for a product, then both Perforce and Bitkeeper are lightyears beyond VSS. If you want free, then there are a variety of choices, Subversion with a local repo probably being the best and easiest (for Windows, at least).
Anyway, even if you *are* a lone developer, branching can be useful. VSS branching sucks, and
trying to merge even more so.
let's not forget that konqueror already "kinda" support the "spatial navigation" - right click, open in new tab.
That's got nothing to do with "spatial navigation". Go read this for
what it's about. The idea is to maintain the properties of real objects. Consider a real file folder. When you put it on your desk, it exists in only one place, and when you come back to it, it's in the same place. When you move, and perhaps open it to look at a particular piece of paper in it, it stays that way, until you change it.
Whether this is good or bad depends on how you like to work. Some research indicates that the spatial metaphor works better for people learning computers, or infrequent users. If you're used to the standard tree browser, it feels odd.
Neuros might have a Linux-version of it's software, but if the player appears as a regural HD to the OS, why would you need dedicated software?
You can put the files on the harddrive or ramdisk, but if you want them to show up in the UI, you have to build the appropriate databases. The DB schemas are documented and there are a few different implementations:
The windows-only one included with the Neuros
Positron, a command line utility in Python.
A Multi-platform GUI in Java, whose name escapes me.
As for size, it's larger than an I-Pod, and probably too big for most people's shirt pockets, but it's not all that big, and is fine in
a beltcase, purse, or in the car, etc. Depends on
how you want use it, I suppose. I chose the Neuros over the Karma mostly because of apparent company support: Digital Innovations actually seems to care if it works with Linux or the Mac, while Rio's support is pretty haphazard.
Nope. Old State law, partially safety driven, partially jobs oriented. Nothing to do with unions. (What union do gasoline attendants belong to, anyay?)
I suppose that was meant to be funny, but "remembers to turn off the projector" is not actually high on my list of desiriable traits in in a teacher. I look for things like "really understands the topic", "able to communicate his/her knowledge", and, for bonus points, "shows enthusiasm for both teaching and learning." Those skills are precious and rare.
Schools lucky enough to have such teachers should
stop griping about projector bulbs and pay some
whiny IT guy $5/hr to follow them around and turn off the projector. Whiny IT guys are a dime a dozen.
It was one of those books that almost discredits the author's other works simply by placing huge doubt on the author's research skills.
So, just like The DaVinci Code, then?
Actually, I gave up on his writing "skills" long
before his research "skills". Not to mention his plotting "skills". Oops, mentioned them, sorry. What an atrocious book TDC was. I'm amazed that anyone who has read TDC would choose to read any other Dan Brown book, even if they didn't know how big a pile of crap TDC was based on. I mean, geeze, he makes Tom Clancy look like a master prose stylist.
I do understand the appeal of conspiracy theory books like TDC, but there's *so* much better out there. Say, anything by Robert Anton Wilson. Or Umberto Eco (well, anything fiction, that is).
I've noticed that autoconf handles this situation very cleanly.
No, it doesn't.
All autoconf does is make it easy to change the hardcoded paths that will be compiled into the package at build time. Once the binaries are built, they have to go into the specified locataions, and the config files into theirs, etc. etc.
It's the people building binary packages that seem to overlook the need for relocation.
The underlying source code usually doesn't support relocation after it's built. There's nothing
the package builders can do about it. Well, they
can rewrite the source to support it, I suppose. That sounds like fun. And I can guarantee that it
won't be tested properly, and it won't cover all the things that you want/need to do, and so you'll
have to rebuild from source anyway. People who run large complicated installations that need custom layouts are going to have to accept the fact that their layouts are just that, custom, and are not, generally, going to be supported by the statndard package system.
I submit that the old guy I saw this morning doing 35 mph along the highway, a 65 mph zone, in the center lane no less...
Said individual was (almost certainly) violating at least one law ("Slower vehicles keep right")
and probably two (most highways that allow speeds of 65mph also have a minimum speed limit >35 mph). One
problem is that neither of those laws is actively enforced anywhere I've lived because it's much easier to generate revenue by setting up a speed trap.
(I say "almost certainly" because suppose some
US states may not actually have this, but I think
most do.)
But I agree with your general thesis that obeying traffic regulations is not the same as safe driving. About 80% of safe driving can be reduced to 3 items:
Go with the flow.
Pay attention to what you're doing: driving
is the most important thing you're doing. Hang up
the phone, put away the food, stop looking at
your kid/girlfriend/boyfried/dog/whatever.
Pay attention to what others are doing: let
people merge and change lanes. If the guy 3 cars ahead of you hits his brakes, backoff now. If someone is coming up behind you, pull over and let
them by, if you can.
All of the above could probably be summed up as "Don't be an asshole", but we as country seem to have lost any respect for courtesy and and personal responsibility, so I know it's a hopeless cause.
...unless you really want/need to support ancient and obscure platforms. But since the question specifically *said* modern and maintained platforms, then autoconf will just uglify and complicate your code.
And in answer to the original question: yes, if you're talking modern unix or unix-like systems (i.e. AIX 4.3 or 5, Solaris 7 or later, Linux/glibc or BSD from the last several years, HPUX 11), then yes, you can assume POSIX and C89 (although for AIX, Solaris, and HPUX you'll need to buy a compiler or install GCC).
The Debian dselect utility did all this (well, it didn't use HTML) in 1995.
You've completely confused patents vs. copyright. Copyrights protect the expression of an idea, and your arguments are more-or-less correct w.r.t. copyrights.
Patents exist to protect an idea. And yes, you can come up with the idea completely independently, and express it differently, but still be in violation of a patent. That's pretty much a requirement for patents to be useful. Otherwise you could just look at the patent but claim you hadn't.
Uh, the whole point is to encourage easy modification, so that the records are up to date.
I'm not sure why we couldn't have just added temp sensors to compensate...
Because the compensation factor varies with the composition, and gasoline composition varies significantly by location and season. It's the sort of thing that reasonable to deal with in refineries and petrochemical plants, less so in small, unmaintained locations.
Content plugins have fairly simple API requirements, basically just a way to say "take this stream of bytes, and display it here. Also, tell me how big a rectangle you need", plus probably few other things.
Browser extensions require knowledge and access to the internals of the specified browser, and doing things liking hooking into calls in internal subroutines. The spec would not only be large, but also put huge limits on the internal implementation of the browser. Ain't going to happen.
How does the peloton know how much speed to pick up to sweep up a break away with a 12 minute lead, 10 km from the finish line?
If the breakaway is 12 minutes ahead 10km from the line, they are not going to be caught, unless they all fall off of their bikes...
Assume the breakaway group/rider is moving at 20kph (not very fast, say it's uphill). They'll finish in 30 minutes. The peloton 12 minutes back has an extra 4km to go (20kph * 0.2h). That means they have to average 28kph to catch the breakaway, or 40% faster. Extremely unlikely. (Yeah, you can slow the speeds down enough to make it work...)
That's pretty much what everyone said about McLaren 1987-90, when they were the dominant team. In '88, Senna and Prost won all the races but one. That was better, though, because you didn't which of Senna or Prost was going to win.
Because they want you to by more books. They are not in the poster business, they are in the book business.
I like dnsmasq and use it on my small home network, but it doesn't meet the requirements of the original poster: forwarding queries to specific servers based on domain name or ip. I realize that such a desire is fundamentally at odds with the way DNS works, but I've had many situations where such a capability would make life a lot easier.
I don't think you fully grasp the problems that the autotools actually do solve for developers.
If the autotools, did, in fact, solve the problems, then I'd have less of an objection. But they don't. They merely mask the problems in copious output, unreadable logs, and bad code. Autoconf is bad enough, but when you get the atrocious automake and libtool plastered on, it's pretty much undecipherable.
The gtk/gnome approach of the *-config script is a much cleaner way of dealing with optional subsystems. Let the library itself tell you where stuff is and how to use it, not some other thing guessing, usually wrong.
As for "provincial", I'm going to guess you haven't done much porting between non-unixlike systems, if you think autoconf is a good thing.
"checking for stdlib.h..." indeed. If you don't have an ISO-C environment, you're so screwed that there's nothing autoconf can do to save you: you don't know how the language works, so whether or not you're missing a few library functions isn't going to make any difference.
I once worked on a fairly large process control system, of which less than 1% was portability code. It ran on Solaris, AIX, HP-UX (this was pre-Linux). It also ran on VMS and WinNT. Most of the portability issues dealt with the entirely different models for process management and memory-mapped files, not with pipsqueek stuff like autoconf.
It's real simple: you read the docs. You determine what the standard actually requires, not what your development system happens to do. And you program to that, then test.
As for the autotools proclaimed ability to port to systems you weren't planning for, that's so much BS. If the system is sufficiently different that ANSI C and POSIX aren't sufficient, then you're going to have to update your code anyway.
Replacing autoconf with some other crutch isn't going to help. Just ditch it entirely.
3. Put all the donations in an envelope, use them honestly, and report them as income to the IRS. Then you don't have to worry.
Of course, if a years worth of donations totals $172.43, then you don't have to worry anyway. Just pay part of your ISP bill and be happy.
There's no need to register a business, unless you are actually doing business, and accepting donations for your hobby doesn't qualify.
All of the above assumes you aren't trying to deduct the expenses of your project, of course. If you actually have enough money traveling around to make doing so worthwhile, then you should create a seperate business, with seperate accounts and everything.
Bullshit yourself. Of course you back up the SCC repository. The problem is that VSS repositories go bad without showing the signs until later. So you have nice backups of corrupt data. Woohoo! And yes, one can sometimes pick through and fix the problem. It's a lovely way to spend the day or weekend.
If you know what you're doing you should never get corrupted files or lose history or anything like that.
Absolutely correct. That should never happen. But we did know what we were doing, and it happened none-the-less. Nor is that a unique experience - Google around and you'll see plenty of experienced people who've had issues with VSS.
VSS may be adequate for a small developer group that never has to support a released product (no useful branching, remember?) and has time to babysit it. But there's nothing it does that CVS doesn't do better, and CVS is free, reliable, and a hell of a lot more capable. In the extremely unlikely event that a CVS repository does go tits up, one can fix the damn thing with a text editor (I think I've had to do this maybe once in several years of heavy CVS use).
Is CVS perfect? Of course not. But there's no reason to recommend VSS over CVS.
SourceSafe.
No, they don't. Which should be a pretty clear warning. Your other comments, though, are dead on!
No, I'm not just dinging it because it's an MS product. I've used VSS extensively, and my conclusion is that you should not put anything valuable into VSS unless you have backup copies elsewhere, which sort of defeats the purpose. It's a fragile POS, breaks at glance, and provides no functionatility that is not better implemented elsewhere and more cheaply. If you're willing to pay for a product, then both Perforce and Bitkeeper are lightyears beyond VSS. If you want free, then there are a variety of choices, Subversion with a local repo probably being the best and easiest (for Windows, at least).
Anyway, even if you *are* a lone developer, branching can be useful. VSS branching sucks, and trying to merge even more so.
This is what you need. Outputs to HTML, Latex, XML. Easy to write, easy to read.
let's not forget that konqueror already "kinda" support the "spatial navigation" - right click, open in new tab.
That's got nothing to do with "spatial navigation". Go read this for what it's about. The idea is to maintain the properties of real objects. Consider a real file folder. When you put it on your desk, it exists in only one place, and when you come back to it, it's in the same place. When you move, and perhaps open it to look at a particular piece of paper in it, it stays that way, until you change it.
Whether this is good or bad depends on how you like to work. Some research indicates that the spatial metaphor works better for people learning computers, or infrequent users. If you're used to the standard tree browser, it feels odd.
Neuros might have a Linux-version of it's software, but if the player appears as a regural HD to the OS, why would you need dedicated software?
You can put the files on the harddrive or ramdisk, but if you want them to show up in the UI, you have to build the appropriate databases. The DB schemas are documented and there are a few different implementations:
- The windows-only one included with the Neuros
- Positron, a command line utility in Python.
- A Multi-platform GUI in Java, whose name escapes me.
As for size, it's larger than an I-Pod, and probably too big for most people's shirt pockets, but it's not all that big, and is fine in a beltcase, purse, or in the car, etc. Depends on how you want use it, I suppose. I chose the Neuros over the Karma mostly because of apparent company support: Digital Innovations actually seems to care if it works with Linux or the Mac, while Rio's support is pretty haphazard.The amperage that will trip each breaker should be printed on it.
And then divide that number by two. Or 1.5, maybe. Anyway, you can't pull 30A (or even 29A) through a 30A breaker, not for very long.
Nope. Old State law, partially safety driven, partially jobs oriented. Nothing to do with unions. (What union do gasoline attendants belong to, anyay?)
I suppose that was meant to be funny, but "remembers to turn off the projector" is not actually high on my list of desiriable traits in in a teacher. I look for things like "really understands the topic", "able to communicate his/her knowledge", and, for bonus points, "shows enthusiasm for both teaching and learning." Those skills are precious and rare. Schools lucky enough to have such teachers should stop griping about projector bulbs and pay some whiny IT guy $5/hr to follow them around and turn off the projector. Whiny IT guys are a dime a dozen.
--
Steve, Whiny IT Guy.
It was one of those books that almost discredits the author's other works simply by placing huge doubt on the author's research skills.
So, just like The DaVinci Code, then?
Actually, I gave up on his writing "skills" long before his research "skills". Not to mention his plotting "skills". Oops, mentioned them, sorry. What an atrocious book TDC was. I'm amazed that anyone who has read TDC would choose to read any other Dan Brown book, even if they didn't know how big a pile of crap TDC was based on. I mean, geeze, he makes Tom Clancy look like a master prose stylist.
I do understand the appeal of conspiracy theory books like TDC, but there's *so* much better out there. Say, anything by Robert Anton Wilson. Or Umberto Eco (well, anything fiction, that is).
I've noticed that autoconf handles this situation very cleanly.
No, it doesn't.
All autoconf does is make it easy to change the hardcoded paths that will be compiled into the package at build time. Once the binaries are built, they have to go into the specified locataions, and the config files into theirs, etc. etc.
It's the people building binary packages that seem to overlook the need for relocation.
The underlying source code usually doesn't support relocation after it's built. There's nothing the package builders can do about it. Well, they can rewrite the source to support it, I suppose. That sounds like fun. And I can guarantee that it won't be tested properly, and it won't cover all the things that you want/need to do, and so you'll have to rebuild from source anyway. People who run large complicated installations that need custom layouts are going to have to accept the fact that their layouts are just that, custom, and are not, generally, going to be supported by the statndard package system.
I submit that the old guy I saw this morning doing 35 mph along the highway, a 65 mph zone, in the center lane no less...
Said individual was (almost certainly) violating at least one law ("Slower vehicles keep right") and probably two (most highways that allow speeds of 65mph also have a minimum speed limit >35 mph). One problem is that neither of those laws is actively enforced anywhere I've lived because it's much easier to generate revenue by setting up a speed trap.
(I say "almost certainly" because suppose some US states may not actually have this, but I think most do.)
But I agree with your general thesis that obeying traffic regulations is not the same as safe driving. About 80% of safe driving can be reduced to 3 items:
All of the above could probably be summed up as "Don't be an asshole", but we as country seem to have lost any respect for courtesy and and personal responsibility, so I know it's a hopeless cause.