Years ago, I had a Sun Enterprise 150 as my "home box" -- it's basically an Ultra-1 with a bunch of disk; looks a lot like an E450.
Anyhow, my cable modem stopped working one day. So, I called tech support, and told them. Long story short, I was a student at the time, and since the University had a deal with Cogeco, they felt obligated to at least not tell me to fuck off because I wasn't running Windows... but they weren't much help, either. After consulting with his boss, my telephone lacky got back to me -- "I'm sorry sir; Suns don't work on the internet".
I felt like reaching right through my phone and choking the living daylights out of him!
It turns out the local cable installer had put a one-way filter on line.
I'm halfway tempted to print up some cheques with the goatse.cx picture on them, make out to the personal account of Darl McBride... and see if he cashes the bastards!
typedef enum { sco, ibm, redhat } vendor_t;/* names of other vendors not actually relevant */
void sue(vendor_t, vendor_t); int counterSue(int);/* Signal Handler */ vendor_t getVendorFromLetterHead(int signal);/* Function call from liblawyer.so */ void consultCEO(const char *, void *);
int main(int argc, const char *argv[])/* Program entry point */ { unsigned long infinite = (unsigned long)-1;/* Portable definition, 1.0 was 16-bit signed */ vendor_t vendor; signal(SIGLAWSUIT, counterSue);
/* For every vendor except SCO, initiate a suit by SCO targeting the vendor */ for (vendor=1; vendor <= infinite; vendor++) sue(sco, vendor); }
Peer Review: (to be confidential inside SCO under standard NDA)
This business plan has several problems:
The function sue() cannot be proven to ever return (see ACM literature re. "Halting Problem"), meaning any suit could effectively last forever.
The function sue() is self-recursive, meaning it could consume all resources available to the machine.
The counterSue() signal handler is poorly implemented and introduces a vulnerability whereby a countersuit DoS attack may be initiated upon Business Plan v2.0; countersuits launched while Business Plan v2.0 is launching a response to another countersuit may go unnoticed, and as such the countersuing vendor would win due to lack of action by the software.
The main() function targets all vendors without attempting to verify if the overhead of calling sue() is justified, nor attempting to execute lawsuits in an optimal order.
No attempt is made to limit the resources consumed (threads spawned) during the counterSue() signal handler; as such, a large number of long-lasting countersuits (again, none of which can be proven to terminate due to the Halting Problem) may use up sufficient resources to prevent the lawsuit loop in main() from initiating new suits, or indeed crash the application program.
The algorithm chosen for sue() has proven only to work once in a specific case (caldera, microsoft); the general case has been proven neither experimentally nor formally. Furthermore, sue(caledera, microsoft) was selected as the test case for this algorithm because it was a trivial example, and the consultCEO() subroutine was significantly more optimized at the time.
(pardon the formatting, I don't think it's *possible* to nicely indent code on./ anymore if you want to have HTML formatting in the same follow-up)
> This is not the appropriate way to duplicate a Solaris install. > Use flash copy. If you're not sure how to use it, do a "man flarcreate".
Hey, thanks. I didn't know about that -- I'll be sure to investigate it tommorow morning.
> I think your ufsdump | ufsrestore trick probably left some > hostid or mac address specific configuration information behind.
Hmm - I thought about nodename/hostname stuff getting left behind (and hunted very hard for some!) -- but that doesn't explain the GUI on the *duped* not working. Or does it? I suppose in a very strange circumstance it could, maybe I oughtta init 0 the duped boxes and see what happens (my latest bunch of boxes aren't production yet, anyhow).
It's frustrating to have so many problems with such a simple task, though -- I really hope I stop having them.:) The SVM GUI (when it works for me) is much faster to use than the SDS GUI, and both are faster (for someone who only sets up boxes every few months) than the command line.
Maybe I should bite the bullet and write a curses TUI.. now how can I justify a couple of days on that...:)
I suppose I could write some nice scripts to do all that, but it would just as complex as meta* given the wildly varying configurations I use.. lately I've been going from the "commands.log" files of similar installations I did under Solaris 8 and tweaking it as appropriate. At least things are simpler now that I don't have to make trans-meta (logging) volumes..
And as for RAM -- you'd think that an idle box with 4GB RAM and 4x450MHz CPUs would be able to run a freakin' disk GUI -- 'specially when the Xserver is on another box!
The new GUI is good when it works, though. Using it, I did my last twin A5200 configuration (including labelling blank disks popping on the right VTOC from the shell) in... get this... 7 minutes. Way faster than I can sit and think about what freakin' switches I need to throw on the command line!
The wierd thing is, one of the hosts in the diskset couldn't run the SVM, the other could. What a load of shit. They were identical fresh Solaris 9 installs -- one duped (ufsdump | ufsrestore) from the other and sys-unconfig'd to the new hostname, even!
When was the last time you flashed the firmware in a COTS harddrive? Does it even work? Are you sure it's *exactly* the same? If you're flashing the firmware, you'd better be!
Same deal with EMC. They support certain disks, and SUPPORT THEM. EMC brackets, BTW, are much harder to come by than Sun brackets..
I can't for the life of me get the SVM to run reliably under Solaris 9 -- most of the time, SMC hangs when I go into "Enhanced Storage".
So, please test and report the following bugs:
- type "smc" and notice how long it takes... four minutes to get to SVM is retarded!
- test smc over lbxproxy
- test smc after sys-unconfig with a new hostname. Try this with and without disksets.
Thanks!:):) I'm getting sick and tired of configuring SVM by hand, it's enough to make me want to downgrade to Solaris 8 so I can run the patched SDS 4.2; it's slow and ornery but it works every time. SVM is very slow and most of the time won't even load for me. Grr.
I have seen strncpy() abused so many times it makes me sick. Like you, I prefer strlcpy(), although I have no idea about the politics behind its adoption in GNU -- I just link in -lgen (the xpg4 lib) under Solaris and code away. I usually have -lgen linked anyhow for strecpy() and such. The Apache Runtime (apr.apache.org) has apr_cpystrn() which is fine, too.
I have actually seen code like this during a code review:
At least that won't overrun, but lord help the guy who tries to put five characters into b.
From the same programmer, I have even seen this:
{
static char a[10];
if (a)
strncpy(a, b, sizeof(a)); }
Okay, the strncpy won't overflow, but what's the point of checking if a is NULL or not?
I like to to this:
{
strncpy(a, b, sizeof(a));
a[sizeof(a) - 1] = (char)0; }..where a is an array of chars and b is a "known good" ASCIZ char *.
I suppose we should point out for the neophytes that strncpy() doesn't write the trailing NUL if it fills the buffer. So the next time you read the string, you're screwed; you have no idea how long it is.
What would you call it? GNM? GNM's Not Music? The problem with that solution, is that most indie music I've heard *is* music, while the non-free stuff often isn't.
The way in which you are criss-crossing your laces and tying your shoes may infringe upon Intellectual Property rights owned by Nike Corporation. As of June 10th 2003, we have terminated Rebok's license to lace their shoes.
Please send us $700 for protection so you don't have to worry about breaking the law and getting sued.
Do you even know what an operating system IS??
on
LSB & Posix Conflicts
·
· Score: 1
> instead of having one big monolithic calcified "OPERATING SYSTEM > COMMANDMENTS FROM GOD",
To paraphrase Andrew Tannenbaum, an Operating System is a program which hides the details about the hardware and presents a nice interface to the programmer. [well, that's one aspect.. others including scheduling, etc., but aren't relevant to this discussion]
Now, how is that interface presented? Function calls would be handy. What are function calls? They are a standard way of passing parameters to another piece of code, executing that code, and return control back to the caller.
One way of doing this is to push the return address on the stack, push the parameters on the stack, jump to the code to execute, execute it, pop the parameters off the stack, pop the return address off the stack, and jump to it. (Note that it doesn't happen exactly like this on any architecture that I'm aware of.. but that's beside the point).
Notice that this discussion hasn't included one character of C code yet -- I'm describing assembler-level operations.
Great! Now we have a way to call functions. But it would be useful to tell programmers how to call them. After all, this is a really annoying description, particularly when calling conventions vary from OS to OS!
_STRING COPY_ Entry point is ELF symbol strcpy Parameters are passed on the stack, the calling routine is expected to clean up the stack. The entry point is to be jumped to as a subroutine jump. The first parameter on the stack is target address Second parameter on the stack is the ASCIZ string to copy. Except under SPARC architecture, where the first stack element described above is actually register %o0 within the current register window, and the second stack element described above is actually register %oi in the current register window. Except under MOS6502 architecture, where the top two bytes of the stack contain the return value as stored by the JSR call and be pushed back to their correct place when the RET is called, and so the first stack parameter described above actually becomes the third stack parameter, and the second stack parameter described above actually becomes the fourth. Except under MIPS architecture where....
...well, you get the idea. So we have to have a better way to describe this. How about this?
void cdecl strcpy(*s1, *s2);
s1 is the target buffer; s2 is an ASCIZ string.
Hmm, seems simpler to me, and contains all of the requisite information. Now, just because the specification is written in C doesn't mean the routine is only callable in C; it's just a specification for a hunk of assembler, for God's sake!
It's not hard to translate the specification for use by another language (I know how to do it in VB for God's sake, and I'm sure it can be done in almost any other crap-language-du-jour... well, except Java, because Java doesn't allow direct interfacing with the OS anyhow).
Note for the pedantic: Yes, I know strcpy() doesn't return void. I was trying to simplify my example by making it procedural.
Note for the uber pedantic: I included cdecl to make the comparison fair, and because it is actually needed under some of the bastard systems out there with multiple calling conventions... examples include MS-DOS, WIN32, and WCE.
Note for the people who are missing the point: Yes, I know strcpy() isn't a real OS call, it's just a handy function for examples, because it's so darned simple.
I agree, popen() or system() shouldn't hang the system. That said, under under certain real unices, they aren't marked thread-safe (Solaris 8, for instance). I'm pretty sure that's corrected under Solaris 9, but I haven't checked.
A reasonable approach might be to use the Apache Runtime for those functions; apr_proc_create(?) combines the ability to do popen/p2open/system into one call which they claim is thread safe, and seems to be from my own experimentation. Well, that, and the fact that they are used for CGIs under Apache 2.x, which seems to be pretty stable.
apr_proc_create is implemented with fork() and xec(), which are marked async-signal-safe under Solaris 8.
That is the STUPIDEST solution I have ever seen!
on
LSB & Posix Conflicts
·
· Score: 2, Informative
It accomplishes NOTHING. First of all, the overflow can still occur if more I/O arrives on stdin between your ungetc and your gets call.
Secondly, if there was no data on stdin (e.g. closed pipe at other end) and you got unlucky during function initialization, you can overrun the dummy buffer with your strlen call. If there is no data, fgets will not alter dummy in any way, there is no guarantee that it is an ASCIZ string, and you call strlen on it. Boom! At least initialize dummy if you want consistent code behaviour.
Third, you're doing way too goddamn much work, and it's EXPENSIVE work!
How about this:
char buf[10]; if (fgets(buf, sizeof(buf), stdin) != NULL)
process_some_data(buf);
Simpler, cheaper, safer, quicker, easier to read, and not retarded!
Not to mention an excellent NIS+ server. Does Linux do NIS+ yet, or is it still NIS only?
An alternative, I suppose, would switching to LDAP-based authentication/hosts... Sun is big on LDAP, LDAP sounds cool, I'll bet Solaris and Linux can both use LDAP in the nsswitch.conf file (although, I must admit, I've never looked nor cared)
40 GB is a lot for one user to type..
on
Lindows Webstation
·
· Score: 1
..I'd be tempted to just dig up an old 40 MB disk. It would still take me a long time to type in 40 MB worth of web bookmarks and letters to my aunt.
> I'm sure that the code produced are of real high quality.
It sure wasn't my best work, but it ran for three years straight (starting the next day) with 100% uptime in an enterprise environment. The only reason it stopped working is because it was no longer needed.
Seriously, get your surfing out the way first thing in the morning. Then sit down and code. It's not hard. If you can't hack that, learn to love coffee. My record is 55 hours of straight coding. What's yours?
..and encrypt your source code and shove it in a repository WAY out of reach of the Sheriff's office, in a very untrackable way.
Like, shove it on a CD, drive 200 miles, and use an internet cafe to upload it to 60 different free web hosting accounts in 30 different countries. If you live in a border town, cross the border. Don't use your credit or ATM card *at all* that trip, and don't buy gas with anything but cash for a week later.
You could pretty much eliminate the acid-spill problem by using Gel-type batteries. These are commonly sold as "maintenance free" batteries for motorcycles (and presumably, cars and trucks too).
Slashdot Mirror
Years ago, I had a Sun Enterprise 150 as my "home box" -- it's basically an Ultra-1 with a bunch of disk; looks a lot like an E450.
Anyhow, my cable modem stopped working one day. So, I called tech support, and told them. Long story short, I was a student at the time, and since the University had a deal with Cogeco, they felt obligated to at least not tell me to fuck off because I wasn't running Windows... but they weren't much help, either. After consulting with his boss, my telephone lacky got back to me -- "I'm sorry sir; Suns don't work on the internet".
I felt like reaching right through my phone and choking the living daylights out of him!
It turns out the local cable installer had put a one-way filter on line.
Assholes.
Don't you slashdot?
Some crackpot in New Zealand is building a cruise missile from COTS part for $3000 US!
Better yet, stop using Linux, lay low 'till they lose in court, and then sue for the cost of not running Linux!
I'm halfway tempted to print up some cheques with the goatse.cx picture on them, make out to the personal account of Darl McBride... and see if he cashes the bastards!
Peer Review: (to be confidential inside SCO under standard NDA)
This business plan has several problems:
- The function sue() cannot be proven to ever return (see ACM literature re. "Halting Problem"), meaning any suit could effectively last forever.
- The function sue() is self-recursive, meaning it could consume all resources available to the machine.
- The counterSue() signal handler is poorly implemented and introduces a vulnerability whereby a countersuit DoS attack may be initiated upon Business Plan v2.0; countersuits launched while Business Plan v2.0 is launching a response to another countersuit may go unnoticed, and as such the countersuing vendor would win due to lack of action by the software.
- The main() function targets all vendors without attempting to verify if the overhead of calling sue() is justified, nor attempting to execute lawsuits in an optimal order.
- No attempt is made to limit the resources consumed (threads spawned) during the counterSue() signal handler; as such, a large number of long-lasting countersuits (again, none of which can be proven to terminate due to the Halting Problem) may use up sufficient resources to prevent the lawsuit loop in main() from initiating new suits, or indeed crash the application program.
- The algorithm chosen for sue() has proven only to work once in a specific case (caldera, microsoft); the general case has been proven neither experimentally nor formally. Furthermore, sue(caledera, microsoft) was selected as the test case for this algorithm because it was a trivial example, and the consultCEO() subroutine was significantly more optimized at the time.
(pardon the formatting, I don't think it's *possible* to nicely indent code on> This is not the appropriate way to duplicate a Solaris install.
:) The SVM GUI (when it works for me) is much faster to use than the SDS GUI, and both are faster (for someone who only sets up boxes every few months) than the command line.
:)
> Use flash copy. If you're not sure how to use it, do a "man flarcreate".
Hey, thanks. I didn't know about that -- I'll be sure to investigate it tommorow morning.
> I think your ufsdump | ufsrestore trick probably left some
> hostid or mac address specific configuration information behind.
Hmm - I thought about nodename/hostname stuff getting left behind (and hunted very hard for some!) -- but that doesn't explain the GUI on the *duped* not working. Or does it? I suppose in a very strange circumstance it could, maybe I oughtta init 0 the duped boxes and see what happens (my latest bunch of boxes aren't production yet, anyhow).
It's frustrating to have so many problems with such a simple task, though -- I really hope I stop having them.
Maybe I should bite the bullet and write a curses TUI.. now how can I justify a couple of days on that...
Maybe it's time I recommend we buy support for our RedHat 8.0-based firewalls. :)
I suppose I could write some nice scripts to do all that, but it would just as complex as meta* given the wildly varying configurations I use.. lately I've been going from the "commands.log" files of similar installations I did under Solaris 8 and tweaking it as appropriate. At least things are simpler now that I don't have to make trans-meta (logging) volumes..
... get this ... 7 minutes. Way faster than I can sit and think about what freakin' switches I need to throw on the command line!
And as for RAM -- you'd think that an idle box with 4GB RAM and 4x450MHz CPUs would be able to run a freakin' disk GUI -- 'specially when the Xserver is on another box!
The new GUI is good when it works, though. Using it, I did my last twin A5200 configuration (including labelling blank disks popping on the right VTOC from the shell) in
The wierd thing is, one of the hosts in the diskset couldn't run the SVM, the other could. What a load of shit. They were identical fresh Solaris 9 installs -- one duped (ufsdump | ufsrestore) from the other and sys-unconfig'd to the new hostname, even!
When was the last time you flashed the firmware in a COTS harddrive? Does it even work? Are you sure it's *exactly* the same? If you're flashing the firmware, you'd better be!
Same deal with EMC. They support certain disks, and SUPPORT THEM. EMC brackets, BTW, are much harder to come by than Sun brackets..
I can't for the life of me get the SVM to run reliably under Solaris 9 -- most of the time, SMC hangs when I go into "Enhanced Storage".
:):) I'm getting sick and tired of configuring SVM by hand, it's enough to make me want to downgrade to Solaris 8 so I can run the patched SDS 4.2; it's slow and ornery but it works every time. SVM is very slow and most of the time won't even load for me. Grr.
So, please test and report the following bugs:
- type "smc" and notice how long it takes... four minutes to get to SVM is retarded!
- test smc over lbxproxy
- test smc after sys-unconfig with a new hostname. Try this with and without disksets.
Thanks!
> a known effect in physic is that the observator modify what he observes ...
It depends on how you define "system". We do not know *anything* about the rules governing an observer outside our universe.
Funny, we always used to say "How do you get a drummer to shut up? Hand him some sheet music!"
I have seen strncpy() abused so many times it makes me sick. Like you, I prefer strlcpy(), although I have no idea about the politics behind its adoption in GNU -- I just link in -lgen (the xpg4 lib) under Solaris and code away. I usually have -lgen linked anyhow for strecpy() and such. The Apache Runtime (apr.apache.org) has apr_cpystrn() which is fine, too.
..where a is an array of chars and b is a "known good" ASCIZ char *.
I have actually seen code like this during a code review:
strncpy(a, b, strlen(b));
What the hell is the point of that?
{
char *a = malloc(10);
strncpy(a, b, sizeof(a));
}
At least that won't overrun, but lord help the guy who tries to put five characters into b.
From the same programmer, I have even seen this:
{
static char a[10];
if (a)
strncpy(a, b, sizeof(a));
}
Okay, the strncpy won't overflow, but what's the point of checking if a is NULL or not?
I like to to this:
{
strncpy(a, b, sizeof(a));
a[sizeof(a) - 1] = (char)0;
}
I suppose we should point out for the neophytes that strncpy() doesn't write the trailing NUL if it fills the buffer. So the next time you read the string, you're screwed; you have no idea how long it is.
> allows for an admin to see if anyone has compromised security, no?
Only if the compromisors are morons, and have done it "recently".
A non moron would type "HISTFILE=" before exiting a shell he'd been "playing" in.
What would you call it? GNM? GNM's Not Music? The problem with that solution, is that most indie music I've heard *is* music, while the non-free stuff often isn't.
The way in which you are criss-crossing your laces and tying your shoes may infringe upon Intellectual Property rights owned by Nike Corporation. As of June 10th 2003, we have terminated Rebok's license to lace their shoes.
Please send us $700 for protection so you don't have to worry about breaking the law and getting sued.
> COMMANDMENTS FROM GOD",
To paraphrase Andrew Tannenbaum, an Operating System is a program which hides the details about the hardware and presents a nice interface to the programmer. [well, that's one aspect.. others including scheduling, etc., but aren't relevant to this discussion]
Now, how is that interface presented? Function calls would be handy. What are function calls? They are a standard way of passing parameters to another piece of code, executing that code, and return control back to the caller.
One way of doing this is to push the return address on the stack, push the parameters on the stack, jump to the code to execute, execute it, pop the parameters off the stack, pop the return address off the stack, and jump to it. (Note that it doesn't happen exactly like this on any architecture that I'm aware of.. but that's beside the point).
Notice that this discussion hasn't included one character of C code yet -- I'm describing assembler-level operations.
Great! Now we have a way to call functions. But it would be useful to tell programmers how to call them. After all, this is a really annoying description, particularly when calling conventions vary from OS to OS!
Hmm, seems simpler to me, and contains all of the requisite information. Now, just because the specification is written in C doesn't mean the routine is only callable in C; it's just a specification for a hunk of assembler, for God's sake!
It's not hard to translate the specification for use by another language (I know how to do it in VB for God's sake, and I'm sure it can be done in almost any other crap-language-du-jour... well, except Java, because Java doesn't allow direct interfacing with the OS anyhow).
Note for the pedantic: Yes, I know strcpy() doesn't return void. I was trying to simplify my example by making it procedural.
Note for the uber pedantic: I included cdecl to make the comparison fair, and because it is actually needed under some of the bastard systems out there with multiple calling conventions... examples include MS-DOS, WIN32, and WCE.
Note for the people who are missing the point: Yes, I know strcpy() isn't a real OS call, it's just a handy function for examples, because it's so darned simple.
I agree, popen() or system() shouldn't hang the system. That said, under under certain real unices, they aren't marked thread-safe (Solaris 8, for instance). I'm pretty sure that's corrected under Solaris 9, but I haven't checked.
A reasonable approach might be to use the Apache Runtime for those functions; apr_proc_create(?) combines the ability to do popen/p2open/system into one call which they claim is thread safe, and seems to be from my own experimentation. Well, that, and the fact that they are used for CGIs under Apache 2.x, which seems to be pretty stable.
apr_proc_create is implemented with fork() and xec(), which are marked async-signal-safe under Solaris 8.
It accomplishes NOTHING. First of all, the overflow can still occur if more I/O arrives on stdin between your ungetc and your gets call.
Secondly, if there was no data on stdin (e.g. closed pipe at other end) and you got unlucky during function initialization, you can overrun the dummy buffer with your strlen call. If there is no data, fgets will not alter dummy in any way, there is no guarantee that it is an ASCIZ string, and you call strlen on it. Boom! At least initialize dummy if you want consistent code behaviour.
Third, you're doing way too goddamn much work, and it's EXPENSIVE work!
How about this:
char buf[10];
if (fgets(buf, sizeof(buf), stdin) != NULL)
process_some_data(buf);
Simpler, cheaper, safer, quicker, easier to read, and not retarded!
Not to mention an excellent NIS+ server. Does Linux do NIS+ yet, or is it still NIS only?
An alternative, I suppose, would switching to LDAP-based authentication/hosts... Sun is big on LDAP, LDAP sounds cool, I'll bet Solaris and Linux can both use LDAP in the nsswitch.conf file (although, I must admit, I've never looked nor cared)
..I'd be tempted to just dig up an old 40 MB disk. It would still take me a long time to type in 40 MB worth of web bookmarks and letters to my aunt.
> I'm sure that the code produced are of real high quality.
It sure wasn't my best work, but it ran for three years straight (starting the next day) with 100% uptime in an enterprise environment. The only reason it stopped working is because it was no longer needed.
Seriously, get your surfing out the way first thing in the morning. Then sit down and code. It's not hard. If you can't hack that, learn to love coffee. My record is 55 hours of straight coding. What's yours?
..and encrypt your source code and shove it in a repository WAY out of reach of the Sheriff's office, in a very untrackable way.
Like, shove it on a CD, drive 200 miles, and use an internet cafe to upload it to 60 different free web hosting accounts in 30 different countries. If you live in a border town, cross the border. Don't use your credit or ATM card *at all* that trip, and don't buy gas with anything but cash for a week later.
You could pretty much eliminate the acid-spill problem by using Gel-type batteries. These are commonly sold as "maintenance free" batteries for motorcycles (and presumably, cars and trucks too).