Re: Basic linux network questions (long)
On Sun, 10 Mar 2002 07:58, Heather wrote:
> The choice of experimenting with crappy APM (because the Beast From Redmond
> implements ACPI so much better than they implement APM, hardware
> manufacturers no longer properly regression test it; I have first hand
> experience with that issue) ...
>
> or with crappy ACPI because software-wise "it's not complete" and in fact
> never will be if people do not use it and report all the big hairy bugs...
>
> ... has to be left to the fellow who asked the question.
True, but I think it should be noted that there's only one likely situation
of serious data loss that seems to be known with APM (that's related to DMA
driven IDE drives operating at the time of suspend).
There have been a number of reports of serious problems with ACPI, and the
code is changing quite rapidly too.
> Reminds me of the quote, "if you left deciding when the project was
> finished to its lead programmer, no software would ever be shrink wrapped."
I see just the opposite, programs that are obviously a longway from what most
people would call a release state being released because they fulfil the
needs of the developer (who incidentally doesn't need manuals so doesn't
notice that the manuals are no good).
> > Yes, hope and pray that your hard drive is not one of those devices that
> > is not quite right...
>
> standard IDE is one of the early things to do right, or why bother? But
> at that point I'm just babbling and no longer offering more than an
> opinion.
It seems that there are still ongoing issues with IDE and APM...
> I'm also not a user running a journaling filesystem for day-to-day use, but
> otoh, if one *knows* they will crash a lot, maybe ext3 is a good idea...
If you know that you'll have a "crash" being total system outage (IE it
suddenly stops and all you can do is press reset) then a journalled file
system is a good idea. If you suspect that it will be of the slow-memory
corruption variety then a journalled file system may do more harm than good
by preventing fsck...
> > I've read that one of the Unix creators once declared that his only
> > regret in life was not calling it create() instead of creat().
>
> I've heard this stated baldly, from the man himself. At the time 12
> UNIX(tm) systems were using the call heavily throughout their software and
> it was considered too onerous to make everybody change it. They were,
> after all, scattered cross-country, and there was a considerable amount of
> latency in software updates as they were limited by the speed of someone
> else's blue station wagon. (bandwidth was pretty good, lots of room for
> tapes in the broad back seat, but still... throughput sucked.)
>
> Waaaaaay too late now.
inline int creat(const char *pathname, mode_t mode)
{
return create(pathname, mode);
}
Put that in one of the system header files and you can rename the function.
Then hack the ELF header of the libc to make a dlsym(handle, "creat") return
the handle for create().
Worse hacks than this are in libc already...
--
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.
Reply to: