> Does windows even have a command line interface that even comes close to the funtionality linux has?
Cygwin?:)
The real answer to your question is yes-and-no. The MS-DOS shell *approaches* the bourne shell in terms of features. It has environment variables, return codes (error levels), branching, output redirection, and pipelining.
The primary problem is that the multitude of "helper" apps -- the apps that make UNIX what it is and define its philosophy (many small, specialized tools working hand-in-hand) just don't exist. For example, I used to have to install Turbo C just to get grep (it came with it).
So, if you can write a script using nothing but the [bourne] shell, you could probably replicate it in MS-DOS (albeit more clumsily). The problem is, writing a script using nothing but the shell generally limits you to writing useless scripts.
With the right dev kit, you can make a CE install with just about set of features you want. It's about the same level of difficulty as rolling a custom Linux distro.. only way more expensive.
> Could you give an example of where this might actually be useful?
I use it in both shell and javascript (njs interpreter) to save and restore state. State is stored in a text file, which, when executed by the running program, magically brings back the variables.
Of course, this is patently evil, and would never see the light of day in production code.
In a similarly evil vein, I have been known to grab a CGI query string in shell, split it across the ampersands, and eval the resulting data as code. This causes the CGI form variables to become shell variables, and your shell-script CGI can then merrily truck along and use them as it sees fit.
I'm not sure which is more evil. They are both useful tricks for writing VERY quick and VERY dirty code, but making them robust enough to expose to users would completely negate any benefits they had. If it was even possible.
Most people forget the -R and assume that ${LD_LIBRARY_PATH} will be set appropriately by the users. IMHO, that's just dumb.
Of course, the example above is not very good if you're also building the strange module's library at the same time as the executable. But I'll leave *that* solution as an EFTS.
Specific instances of "render slowly" will vary from browser to browser. NS3 would display nothing at all from the image point onward; in your brower's case, it makes the text reflow awkwardly.
Regardless of the behaviour, specifying the image size will allow the page to be rendered more quickly.
Rendered, in this case, has a binary meaning. Either the page is fully rendered, or isn't.
Ah, thanks for pointing out the subtlety I'd missed -- you (and the OP) are right, of course -- everything really should be specified using the same units. I thought he was asking "why specify image size at all".
Now, if only the browsers would do a better job dynamically resizing images in the first darned place...
> Try laying-out a page on a 110dpi screen using point-size fonts and pixel-size images, > then display that same page on a 96dpi (or less) mobile device.
You don't even need to go the mobile domain to see this issue. I configure my windows boxen for 1024x768 resolution, 125% fonts, because I'm old and blind and don't like 800x600 for graphics work (I suppose I could just buy a 21" monitor and be done with it....) This subtly breaks almost everything on the planet (not just web pages); particularly forms with drop-down boxes and such.
> Funny thing is, a single drive can take a RAID down.
Which is why when *I* do RAID for production systems, I run RAID 1+0, with one stripe per enclosure, one enclosure per host bus adapter, and separate hot spare pools for each stripe (co-located within the same enclosure). If I'm running something like Sun A5x00 arrays, I sometimes go even further and use two HBAs per loop and split the array down the middle (which eliminates most single points of failure within the array -- "split loop mode"). The extra cost of the HBA is more than worth the piece of mind (those boxes can hold 22 disks); the mild performance boost is icing on the cake.
BTW, your comments about one disc taking out the bus also applies to FC_AL... even though it shouldn't. I took have had hot spare "accidents", but have yet not lost any data, nor had a serious outage. Knock on wood. I have even done live drive-replacement on multi-hosted SCSI-II, *non-hotswap* without downtime -- but I had good backups and it still gave me an ulcer (break the mirror, power down the enclosure, cold-swap, power-up, restripe).
This is not true at all levels of education. In particular, elementary school children would do well to cite an encyclopedia. Doing so teaches good habits (cite your sources) without requiring them to go to impractical extremes, such as making sense out of scientific journals.
And yes, elementary school teachers are accepting websites as sources. Considering the discerning skills of the children in question, Wikipedia is not a bad place for them to do their research.
It's sure a lot better than having your kids randomly visit "bears.com".
> My bad, Britian and Iserail are actual valid alternative names.
If it makes you feel any better, English is my *first* language, and I've never heard of those spellings. In fact, I'm quite convinced they are either non-anglo or simply incorrect.
> The hilarious part is that you are actually wrong. Your speculation -- > and your arrogance in assuming it is correct -- is exactly the kind of > stupidity that the guy was complaining about.
Well, at the very least, nobody accused me of being dishonest. Perhaps I should have exchanged "arrogant" and "experienced" in my original post, however.:)
> Their server replies after the first packet because they DO NOT CARE about the > information in the request. The server always gives exactly the same reply to > the request, so for simplicity of implementation they just had it reply right > away.
Actually, they *do* care about the information in the request. Requesting docroot of a "nameless" (i.e. HTTP/1.0) server yields the moronic redirect, to and from/?ACBDEFG.
The interesting thing, however, is that *if* you construct your first packet to contain both the GET and the Host header, you get the website in question.................
Okay, I take back everything I said up there, *and* the day before. A little more digging (120s this time) has revealed something interesting.
The redirect is *not* based on the construction of the packet as I had originally surmised. (I had originally assumed they were doing proxy/NAT based on VHOST, which, while odd is not totally insane).
> If I were to guess at the real cause, I would blame the fact that they're > redirecting from / to/?ABCDEFGH and then back to / again. The second time you > hit/, it actually displays the site.
Close. It's the "second time" part that's a red herring.
Sometimes, the server waits for the entire header; sometimes it does not. If it does, you will get the website you're looking for; if it does not wait, you will not.
Whether it waits or not is independant of the URL requested. If it does not wait the HTTP connection is immediately closed. If it does wait, you will get a genuine HTTP/1.1 keepalived connection, and further requests on this connection are not subject to the redirect. Which behaviour is exhibited seems (to me) random, and it waxes and wanes. This strongly suggests that it is load-driven.
So, the redirect is just a "dance" to get your machine to bounce off the remote until it can finally make the request properly. This, IMNSHO, is *really* stupid.
If you're just bouncing off one machine in the back end, increasing your queue length (arg to accept()) would be a lot easier on the box and should not decrease your server capacity (unless you have some kind of major architectural problem).
If it's trying to redirect you and help you randomly find an available host, that just a moronic algorithm.
Any way you look at it, it appears to be a "clever" solution to a bigger problem; the type that intermediate programmers often come up with.:) "clever" problems almost always invariably bite you in the ass when exposed to the real world.
That said -- it does appear to be completely legal HTTP/1.1, including cache semantics for status 302.
So -- Safari and Opera *are* in fact broken, -but- the act that breaks them is, IMNSHO, moronic. The entertaining thing is that this will sometimes work, and sometimes break.
I'd love to know what kind of load balancing hardware they are using in front of these things. They don't look like they're actually serving up any pages, just generating framesets with mod_pointer. Any idea how many domains GoDaddy is doing like this? A single Sun 40z, barenaked on the 'net, should be able to handle a metric-assload of this traffic type, all for the low, low price of [some figure which is lower than the cost of bad PR]..... I'd guestimate that I could get the 40z to easily serve up 3,000 pages per second with this config, but the bottleneck might well be mySQL (which would then get quickly replaced with a bdb replica or something).
> PS. Nice job breaking Slash (so to speak) with your username...
LOL, thanks. It wasn't on purpose, I guess slashcode just had bad input validation back then. I wonder if it still does? IIRC, my user page didn't actually break 'till sometime in '99.
Slashdot Mirror
> Does windows even have a command line interface that even comes close to the funtionality linux has?
:)
Cygwin?
The real answer to your question is yes-and-no. The MS-DOS shell *approaches* the bourne shell in terms of features. It has environment variables, return codes (error levels), branching, output redirection, and pipelining.
The primary problem is that the multitude of "helper" apps -- the apps that make UNIX what it is and define its philosophy (many small, specialized tools working hand-in-hand) just don't exist. For example, I used to have to install Turbo C just to get grep (it came with it).
So, if you can write a script using nothing but the [bourne] shell, you could probably replicate it in MS-DOS (albeit more clumsily). The problem is, writing a script using nothing but the shell generally limits you to writing useless scripts.
With the right dev kit, you can make a CE install with just about set of features you want. It's about the same level of difficulty as rolling a custom Linux distro.. only way more expensive.
'95 will run on a 386-40 with 4MB of RAM.
It's quite usable, too, if the only app you want to run is Word 6.
I don't know squat about WindowMaker, but FVWM 1.24 was my window manager of choice on 486 and is *still* my window manager of choice.
Yes, old habits die hard. And make my current boxes seem REALLY FAST.
No, it wouldn't. The cylinder sleeves would still need to be cast iron or ceramic or something.
Of course it is. Hell, you can HEAR it.
Assuming, of course, you're trying to load a single, large file -- not a billion little ones.
Poland isn't a language.
Your math is flawed -- unless you have actually had to wipe your Linux box due to a virus, Windows is infinitely more likely to have a virus.
Or, to put it in Redmond-speak:
? DIVISION BY ZERO
READY.
> Range is 3200 nm with a full payload.
You know, if I had to move a heavy object 3200 nanometers, I'd just hire a couple of high school kids. Bound to be cheaper.
> Could you give an example of where this might actually be useful?
I use it in both shell and javascript (njs interpreter) to save and restore state. State is stored in a text file, which, when executed by the running program, magically brings back the variables.
Of course, this is patently evil, and would never see the light of day in production code.
In a similarly evil vein, I have been known to grab a CGI query string in shell, split it across the ampersands, and eval the resulting data as code. This causes the CGI form variables to become shell variables, and your shell-script CGI can then merrily truck along and use them as it sees fit.
I'm not sure which is more evil. They are both useful tricks for writing VERY quick and VERY dirty code, but making them robust enough to expose to users would completely negate any benefits they had. If it was even possible.
That said, if you're using gcc and GNU make, you may prefer the following:
/usr/local/strange_module-2.3.7
PREFIX =
CPPFLAGS += -I$(PREFIX)/include
LDFLAGS += -L$(PREFIX)/lib -R$(PREFIX)/lib
Most people forget the -R and assume that ${LD_LIBRARY_PATH} will be set appropriately by the users. IMHO, that's just dumb.
Of course, the example above is not very good if you're also building the strange module's library at the same time as the executable. But I'll leave *that* solution as an EFTS.
So, now will all those mysterious icoo:// movie links work in Firefox?
Specific instances of "render slowly" will vary from browser to browser. NS3 would display nothing at all from the image point onward; in your brower's case, it makes the text reflow awkwardly.
Regardless of the behaviour, specifying the image size will allow the page to be rendered more quickly.
Rendered, in this case, has a binary meaning. Either the page is fully rendered, or isn't.
And if all that doesn't work, just tell her your penis is sore. Maybe she'll offer to rub it.
Ah, thanks for pointing out the subtlety I'd missed -- you (and the OP) are right, of course -- everything really should be specified using the same units. I thought he was asking "why specify image size at all".
Now, if only the browsers would do a better job dynamically resizing images in the first darned place...
> Try laying-out a page on a 110dpi screen using point-size fonts and pixel-size images,
> then display that same page on a 96dpi (or less) mobile device.
You don't even need to go the mobile domain to see this issue. I configure my windows boxen for 1024x768 resolution, 125% fonts, because I'm old and blind and don't like 800x600 for graphics work (I suppose I could just buy a 21" monitor and be done with it....) This subtly breaks almost everything on the planet (not just web pages); particularly forms with drop-down boxes and such.
> Why should you specify pixel dimensions on images?
The page will render faster if the browser knows the dimensions of the image before downloading it.
This is especially critical for dial-up and wireless (assuming the wireless browser even has images enabled).
> Funny thing is, a single drive can take a RAID down.
Which is why when *I* do RAID for production systems, I run RAID 1+0, with one stripe per enclosure, one enclosure per host bus adapter, and separate hot spare pools for each stripe (co-located within the same enclosure). If I'm running something like Sun A5x00 arrays, I sometimes go even further and use two HBAs per loop and split the array down the middle (which eliminates most single points of failure within the array -- "split loop mode"). The extra cost of the HBA is more than worth the piece of mind (those boxes can hold 22 disks); the mild performance boost is icing on the cake.
BTW, your comments about one disc taking out the bus also applies to FC_AL... even though it shouldn't. I took have had hot spare "accidents", but have yet not lost any data, nor had a serious outage. Knock on wood. I have even done live drive-replacement on multi-hosted SCSI-II, *non-hotswap* without downtime -- but I had good backups and it still gave me an ulcer (break the mirror, power down the enclosure, cold-swap, power-up, restripe).
> ...to call blog content "data".
They still call all that stuff between the genes "DNA"
You know, I've noticed that hard drives fail quite often, and take a lot of data with them.
Somebody really should invent some method of making a single disk failure a non-issue; perhaps, by using a redundant array of independant drives...
This is not true at all levels of education. In particular, elementary school children would do well to cite an encyclopedia. Doing so teaches good habits (cite your sources) without requiring them to go to impractical extremes, such as making sense out of scientific journals.
And yes, elementary school teachers are accepting websites as sources. Considering the discerning skills of the children in question, Wikipedia is not a bad place for them to do their research.
It's sure a lot better than having your kids randomly visit "bears.com".
> My bad, Britian and Iserail are actual valid alternative names.
If it makes you feel any better, English is my *first* language, and I've never heard of those spellings. In fact, I'm quite convinced they are either non-anglo or simply incorrect.
If you use the new ip2 stuff, you can route to "blackhole" instead of the local interface. A little cheaper, and a few less keystrokes.
:)
ip route add blackhole cidr
IIRC (rtfmp if I'm wrong.
Gee, and fifteen years ago (probably more, actually), MIT co-opted that word for X-windows widgets. You know, like, the Athena widgets set?
Try doing a "man -k widget" on a modern OS, you may become very surprised. Especially if you have Tcl/Tk installed.
No, Alf claimed the other planets were named Alvin and Simon.
> The hilarious part is that you are actually wrong. Your speculation --
:)
/?ACBDEFG.
................
/?ABCDEFGH and then back to / again. The second time you /, it actually displays the site.
:) "clever" problems almost always invariably bite you in the ass when exposed to the real world.
> and your arrogance in assuming it is correct -- is exactly the kind of
> stupidity that the guy was complaining about.
Well, at the very least, nobody accused me of being dishonest. Perhaps I should have exchanged "arrogant" and "experienced" in my original post, however.
> Their server replies after the first packet because they DO NOT CARE about the
> information in the request. The server always gives exactly the same reply to
> the request, so for simplicity of implementation they just had it reply right
> away.
Actually, they *do* care about the information in the request. Requesting docroot of a "nameless" (i.e. HTTP/1.0) server yields the moronic redirect, to and from
The interesting thing, however, is that *if* you construct your first packet to contain both the GET and the Host header, you get the website in question.
Okay, I take back everything I said up there, *and* the day before. A little more digging (120s this time) has revealed something interesting.
The redirect is *not* based on the construction of the packet as I had originally surmised. (I had originally assumed they were doing proxy/NAT based on VHOST, which, while odd is not totally insane).
> If I were to guess at the real cause, I would blame the fact that they're
> redirecting from / to
> hit
Close. It's the "second time" part that's a red herring.
Sometimes, the server waits for the entire header; sometimes it does not. If it does, you will get the website you're looking for; if it does not wait, you will not.
Whether it waits or not is independant of the URL requested. If it does not wait the HTTP connection is immediately closed. If it does wait, you will get a genuine HTTP/1.1 keepalived connection, and further requests on this connection are not subject to the redirect. Which behaviour is exhibited seems (to me) random, and it waxes and wanes. This strongly suggests that it is load-driven.
So, the redirect is just a "dance" to get your machine to bounce off the remote until it can finally make the request properly. This, IMNSHO, is *really* stupid.
If you're just bouncing off one machine in the back end, increasing your queue length (arg to accept()) would be a lot easier on the box and should not decrease your server capacity (unless you have some kind of major architectural problem).
If it's trying to redirect you and help you randomly find an available host, that just a moronic algorithm.
Any way you look at it, it appears to be a "clever" solution to a bigger problem; the type that intermediate programmers often come up with.
That said -- it does appear to be completely legal HTTP/1.1, including cache semantics for status 302.
So -- Safari and Opera *are* in fact broken, -but- the act that breaks them is, IMNSHO, moronic. The entertaining thing is that this will sometimes work, and sometimes break.
I'd love to know what kind of load balancing hardware they are using in front of these things. They don't look like they're actually serving up any pages, just generating framesets with mod_pointer. Any idea how many domains GoDaddy is doing like this? A single Sun 40z, barenaked on the 'net, should be able to handle a metric-assload of this traffic type, all for the low, low price of [some figure which is lower than the cost of bad PR]..... I'd guestimate that I could get the 40z to easily serve up 3,000 pages per second with this config, but the bottleneck might well be mySQL (which would then get quickly replaced with a bdb replica or something).
> PS. Nice job breaking Slash (so to speak) with your username...
LOL, thanks. It wasn't on purpose, I guess slashcode just had bad input validation back then. I wonder if it still does? IIRC, my user page didn't actually break 'till sometime in '99.