> They need to work X hours at Y dollars an hour to achieve self-susteinance. > With your plan, the employees make only half of what they used to.
You don't implement such a thing suddenly, cutting everybody's hours in half overnight and hiring a bunch more half-timers to fill out the schedule. What you do is, when you hire new "full-time" people (e.g. as a result of turnover), you hire them for 30-35 hours, instead of 40. Also if possible you hire a couple of part-timers for 20-25 hours. Then when you need to keep somebody over past the scheduled end of their shift, you pick one of these people. In time, you can convert your entire staff to being scheduled 30 or fewer hours and actually working less than 40 almost 100% of the time.
Yes, *some* employees will be annoyed because they'll want 40 hours, and they might even look for work elsewhere, but there are other people who will be grateful not to be made to work overtime all the time because they prefer to have some time left for other stuff. Six of one, half a dozen of the other, but you can pay out less overtime this way, if that's your goal.
This does not, however, solve the scenerio where the higher-ups tell you to run the place with less than such-and-such payroll.
When I worked at McDonald's, the system they used was to watch what payroll was costing *as a percentage of gross* on an hour-by-hour basis. If it got to be too high, they sent somebody home. This system had the advantage in general of not sending home employees who were sorely needed to keep the place running, because if we were busy then gross was high enough to support more employees.
As far as I am aware (and I *think* I would have noticed, though it's hard to be entirely certain), I have never seen time shaved per se at any place where I've worked. I *have* seen all time rounded off to the nearest quarter-hour, at places where timesheets are filled out with pen and paper and the person doing payroll doesn't want to do complicated calculations. But the employees did their own rounding. I'm not sure of the legality of this arrangement (I suspect it's dubious at best), but it's not as near as I can tell designed with the intention of cheating employees (if anything, the employees could easily round up if it's even close); the goal is simplification. I was always uncomfortable with it, though, and as I said I'm unsure of the legality. I've also seen various other technically illegal things...
I have seen a situation where "comp time" was heavily abused to shift time from heavy weeks onto light weeks; I personally wouldn't have stood for it, but the employee wasn't me but someone else I know, and he didn't even see the problem when I explained it to him or seem to mind, so I let it go as not my problem.
I've seen break times recorded as different from when the breaks were really taken, to hide the fact that the employee worked more than five consecutive hours between breaks. The employees did get the break, though, just not at the time the records said. I've also seen employees voluntarily forego breaks that _technically_ they legally have to have, and the employer permitted it, which they legally aren't supposed to do. There was no _pressure_ to forego breaks though, at least, nothing that could really be construed as strong or direct pressure. (The place was busy and the other employees busting themselves, and the person knew it, but nobody would have objected if he took the break, and he knew that too. Call it pressure if you want.) Again, this is definitely not legal, but it's also not quite the same as the shaving discussed in the article.
I've seen (non-payroll) records falsified. I refused to participate, so someone else did it. She was annoyed, but no action was taken against me.
I've seen managers instruct employees to do things that everyone present knew was offi
> Are you suggesting all stores should hire 6-12+ people and simply keep them > on retainer on the off chance that they're needed for those 2-4 hours a week > most overtimes accrue to?
No, what you do is schedule your employees fewer than 40 hours. The ones who insist they really need 40 hours, you give them 38-39 and make them leave on time. If you need to keep somebody over, you don't take volunteers; you keep somebody who only works 30-35 hours most weeks.
And yes, once in a while you'll have a situation where you really have no choice but to give somebody overtime. But if it's happening on a weekly basis, you've scheduled people too close to 40 hours and given up your flexibility by doing so.
> can't remember a time when the Mac OS wasn't better than the comparable > Windows version available at the time.
In all respects except maybe security, this is a pretty bogus claim. MacOS was *different*, but it was not objectively *better* and in many ways was a good deal *worse*. For example, Windows 95 OSR2 had real multitaking -- actual, factual, preemptive multitasking -- in 1996. MacOS didn't get it until OS X came out. We're talking here about an important key feature that *good* systems have had since the seventies: the ability for any random application to be running at the same time as any other random application, and the system doesn't freeze up for seconds-on-end while you wait for something to finish; each application is responsive as if it were running all the time (because, it is). So you can click on a link in Mozilla and *immediately* switch to another window and do stuff while you wait for the page to load. In MacOS 9.1, you can't do this; the browser monopolizes the system, as if the whole OS were frozen up (in a sense, it is), waiting for the page to load. This is a really big deal. It is, of course, fixed in OS X. But Windows had this in late 1995 (sooner, if you count NT).
Then there's the dock. The Mac dock today (and since 10.0) is better than anything Windows will have at least until Longhorn comes out[1], but prior to that there was... there was... well, there was that little thing in the upper-right-hand corner, a holdover from the System 6 Multifinder, that shows which app is running, and you can pull it down and switch to a different one. And the menubar at the top did have a clock. But there was nothing that really could pass for an actual dock, bar, or panel.
Windows also has had, since 1995 or before, better memory management than MacOS 9. This really shows up if you have more apps open than will fit in RAM all at once. The classic Mac does not perform well under these conditions; Windows 95 handles it much better; you only really notice the swapping delays when you switch between applications. Additionally, Windows 95 does not require the user to configure VM manually, as MacOS 9 does. (Windows 3.1 did require this; going to automatic handling of virtual memory was a major leap forward in 1995.)
The Apple HIG is arguably better and certainly more closely followed by most ISVs, but there are other niggly things about the Mac interface that suck in ways that almost make up for that. With the Classic Mac you basically *have* to have a third-party macro application, for example, because way too few things have keyboard shortcuts. (The mouse is great for discovering stuff you didn't know how to do, but it sucks for quickly doing something that you do very frequently.) Keyboard shortcuts are much more common in the Windows world (and almost totally universal in the *nix world). OS X is starting to fix this (though there is still more to be done).
There are other things. To say that the MacOS is better than Windows *now* is a fairly credible claim; to say that it has *always* been better than the Windows available at the time is... bogus.
Although, in the Windows 3.1 days, I'd agree that the Mac system was better. (I didn't use Windows much back then, though; I used DOS:-)
[1] Gnome, however, is in some ways better. Notably, the applets are better,
and the Mac dock doesn't support drawers, which are IMO a killer feature.
The icon zooming on the Mac dock is better, however, and unifying the
running process list with the launchers, only listing a given app once
and indicating that it's running with the little arrow underneath, is a
nice touch. But the Windows taskbar is clearly inferior. But it was
better in 1995 than anything equivalent that the Mac had to offer until
OS X came out. It took Apple four or five years to catch on to this.
Some of what he says is right.
on
Gates on Winsecurity
·
· Score: 5, Interesting
No, not everything, of course. But some of what he says is right. Much of the bits about isolation and resiliency are dead on the money: having the firewall on by default is a start, but if I understand correctly what he's saying (which is hard, because the wording is brief and nontechnical; it was obviously not written for a technically-inclined audience), Microsoft intends to actually *fix* Outlook. Not "patch" it to stop a particular exploit, but actually fix the root problem.
He also says some stuff that's good to hear despite not really constituting security -- e.g., popup blocking, and not loading remote content in email.
He also talks about taking measures at the system level to mitigate the risk of buffer overruns, but I can't tell from what he says whether what they're doing there will be helpful or a placebo. This is where the CPU NX stuff comes in, and I'm a little over my head there; I understand the idea, but I don't think I grok all of the implications.
This is actually a good article. Not perfect, but good. Go read it, those of you who haven't yet. I don't think we're going to slashdot Microsoft.
Really aweful doesn't even cover it. Windows 95 was really aweful. MacOS 9 (and earlier) was hideously and unforgivably Dain Brammaged. It's the only OS I've seen that manages to combine worse error messages than DOS[1] with worse memory management than Windows 3.1, while _claiming_ to have a great GUI but not supporting such basic features as minimize and maximize, yet also _claiming_ to support multitasking but in fact freezing up whenever any app does anything. Classic can't die soon enough to suit me.
But note that I'm not anti-Apple anymore. Mac OS X is so much better than MacOS 9, it's like the difference between night in a cave and noon on a mountaintop. It's still not my favourite system, but it's a decent and viable OS, and I feel good about calling it one of the "big three" (the other two being Windows and *nix); before OS X, I cringed just thinking about Mac being one of the big three system types.
[1] "Error: An error of type -876344 occurred." I've seen better error
messages written by high-school students the first week of BASIC class.
By comparison, "Error reading drive A: Abort, Retry, Ignore, Fail?"
is a veritable fountain of information about what the problem is and
what can be done about it.
> a number of !boot viruses, that could infect your machine even if you > just opened a filer view onto a floppy. Not even Windows can do that:-)
Actually, Windows _can_ do that with CDs, unless you use TweakUI or regedit to turn off the AutoPlay "feature". This was less of a problem when CD burners were cost-prohibitive for most users, because people who caught anything this way couldn't spread it around, since they didn't have a burner. It worries me now, with burners being common these days. I always turn AutoPlay off on Windows systems that I administer.
> So does having real division rather than floor division by default.
I think BASIC has real division by default, except of course that it's limited by whatever data type you're working with. What I really want (and we're *hopefully* getting it in Perl6) is numbers that automatically promote themselves to bignums if necessary, so that there's no such thing as overflow. Perl5 already promotes integers to floats as necessary, of course.
> And I believe its integer (no suffix) and double%, in BASIC
I'm pretty sure of integer%, since I used that quite a bit (in GWBASIC and later QBasic). I'm a lot less sure about double, because I almost never did anything in BASIC that needed floating point numbers.
Trivia point: in some implementions of BASIC, foo$ and foo% and so on are all different variables, like @foo and %foo in Perl5. Use of this feature is generally discouraged in beginning courses, however, since overuse of it can create (minor) obfuscatory effects, _especially_ with overly laconic variable names.
> A ground-breaking new game ported to OS X? Yeah, like anyone's going to > believe THAT!
You display your ignorance. Anything written in Inform doesn't *have* to be ported to OS X, or for that matter to any other platform. Inform compiles to zcode, which is the second-most-portable format after 7-bit ASCII text. (Or *possibly* third after HTML3.2, but that's debatable.) The format was designed by Infocom so that they wouldn't have to create different versions of their games (starting with zork) for each different platform they wanted to release on. There are z-machine emulators (known in the interactive fiction community as "interpreters") available for hundreds of platforms, platforms you've never heard of. The guy who wrote Inform uses something called Archimedes which runs on a hardware architecture called Acorn, for example. Other supported platforms include the TRS-80, tenex, Gameboy, the BBC Micro, Emacs, Mozilla (yes, there's a Firefox extension), Apple// series, IBM mainframes, the Java VM (yeah, a vm inside a vm),... you get the idea. Runs On Everything. zcode is supported on more platforms than GIF and JPG, because almost a third of the platforms it runs on don't have graphics.
For OS X you have your choice of several dozen emulators ("interpreters"), the most popular ones being MaxZip (native to MacOS, been around forever, way before OS X) and frotz (for either Terminal.app or X11 if you get Apple's X server, also been around forever but more cross-platform).
The user does have to download an emulator ("interpreter") though. If your platform is at all common you can get one from ifarchive.org for example.
> You could try teaching them LOGO or lisp, but lisp is boring
So go for a variant, like elisp or Scheme. elisp has the advantage of being immediately useful, because you give them Emacs to use as an editor, and the first thing everyone needs to do is change the keybindings, so you teach them enough lisp to do that, and then you introduce them to some other thing they'll want to customize, and teach them enough more lisp to do that... pretty soon you've got them writing their own major modes and talking about wishing Emacs supported forking or threading, at which point you can introduce them to Scheme and start warp^H^H^H^Hstretching their minds around concepts like continuations.
I prefer Perl, though. Yeah, it's case-sensitive, but you just teach them to do everything in lowercase except for filehandles (uppercase) and modules (usually Title::Case::Like::This, but however it's listed on search.cpan.org). And yeah, there's more to learn in Perl than BASIC, but if you skip all the functionality that's just plain _missing_ in BASIC (regexes, lexical and dynamic scoping, packages and modules (except core pragmas, which correspond roughly to the OPTION statement in BASIC), references, list transformations like map and grep, formats (who uses those anyway?), printf and sprintf, most of the special variables, typeglobs, the functional paradigm, objects,...) then there's not nearly as much to teach 'em as there would be if you had to teach the whole language. The only major concept you really *have* to cover that's not present in BASIC is context. (Sigils actually have an analog in BASIC, though in BASIC they're a suffix rather than a prefix and the types are broken down differently, but it's the same basic idea, string$, integer%, single! and double# (did I reverse those? It's been so long...), and long&, verses $scalar, @array, %hash, &code, and *glob. As mentioned, you don't have to cover typeglobs, and you don't really need to cover coderefs either, so the & sigil can be skipped in a beginner course, leaving only three, comparable to the big three ($, %, and one of the float types, take your pick) for BASIC.)
If I wanted to do a beginner course in object-oriented programming, I'd use Inform, on the grounds that virtually everyone with even slight geekish tendencies can get "into" the problem domain it's intended to solve, and also because the Designer's Manual is superb, and because its object model is fairly complete, with a full object forest, nested inheritance, multi-inheritance, easy instance objects (i.e., overriding inherited stuff on a per-object basis) -- all the goodies. Also, Inform is very easy to learn, and it's especially easy to read. It's not general-purpose at all, but for learning OO concepts that doesn't matter.
> > Isn't it about time we ditched 20-year-old TV sets for something better? > New TVs, available at your local stores.
Umm... isn't it about time we ditched the whole _concept of TV for something better? Oh, wait... some of us already have, and it's called the _internet_.
> > Isn't it about time we ditched COBOL for something better? > Visual Basic.
Wow. I have, umm, mixed feelings about whether VB is better than COBOL. I mean, I took a COBOL class in college, and it was, like, bad, but then, I also took a VB class, and it was, like, bad...
> > Isn't it about time we ditched BASIC for something better? > Uhm... it's for beginners. We can't ditch the biginners...
There are other languages for beginners. Not that BASIC as really bad per se (hey, I learned to program using BASIC...), but it's not the only option.
> > Isn't it about time we ditched Dubya for something better? > John Kerry
Ugh. Can't the Dems do better than him? (Okay, so he seems more alive than Gore, so I guess that could count as an improvement...)
My dad thinks the Dems deliberately avoided putting any viable candidate on their ticket this time, because they want Bush to win so they can run Hillary next time against Cheney. He says they figured running her against Bush would be too risky, she might lose, and it would poison her career. Well, that's what my dad says. Maybe he's finally lost it, I don't know, he is starting to get old... but I've heard much crazier theories.
>...mirrors would need to be in sync at all times for this to work.
This could be solved with versioning, as long as any given file is always seeded/uploaded on the same server initially (say, on the server of the person who is publishing the file).
Well, there's Net::BitTorrent::File, but this seems to be for use on the distribution end. Presumably the client
would be Net::BitTorrent::Client, but that doesn't seem to exist yet. But
BitTorrent has only really just started to catch on big-time in the last few
months, so I'm sure someone will get to it before too long. A Mozilla plugin
sounds like a good idea too, but that might be longer in coming.
Once a month I have to go to the bank and deposit my paycheck, lest I run out of usable funds. Fortunately the bank is right nextdoor to where I work, so I generally can just leave for work five minutes early and go to the bank on the way, so it only adds a couple of minutes to my total time outdoors for the month. Also any time I want to mail something (like, say, the checks to pay my phone bill and ISP once a month) I have to go to the post office. But fortunately the post office is just across the street from the bank, so I usually go when I go to the bank, and just leave another five minutes earlier, only adding another couple of minutes to my total time outdoors for the month. If I have to buy stamps, I do that at the same time.
No, I'm not joking. The above is all true. Okay, I'm joking a little in that the above reasons are not the *only* times I get out. I also go to church, and occasionally I go to the hardware store (one block past the post office) or some other place. Once in a great while (read: several years) I take the dog for a nice long walk (read: several hours at one go) on a day off, just because. Also occasionally I go for a walk by myself for a while, just because. Usually I do this at an odd time, like the middle of the night, when nobody's out. (I live in a relatively small community; at 3am you can cross the biggest streets in town at your leisure without looking.) That's my favourite time to go for a walk, because I can think out loud, wave my arms around, gesturing to myself or an imagined audience, and just generally do stuff that's only kosher to do in our society when you're alone, stuff that gets me funny looks even from my immediate family -- but sometimes it's nice to be able to cut loose like that someplace where you've got plenty of room to walk around, such as outside.
> People jokingly announce really cool things that have no chance in hell of > ever coming out.
I know. I'm still bummed about the George Foreman USB iGrill, too.
It's interesting, though, that the interactive fiction community (see for example rec.arts.int-fiction on usenet) has a history of announcing really cool things on April 1 that _were_ real. Okay, RAIF-POOL wasn't real, but glulx was announced on April 1, and I'm thinking that either Inform version 6 or the Designer's Manual version 4 was announced on April 1 too. Also, the community's number one vaporware product of all time, Avalon, when it was finally actually released (albeit not under the original name; I now forget the name it was released under) was announced on April 1. Or maybe it was when it was made available for free download. Anyway, it was a long-standing joke and much-desired event and when it finally happened for real it was announced on April 1. Pretty decent game, too.
Here's an actual snippet, taken from a game I was working on years ago. Sorry about the thin-to-nonexistant indentation, but the postercomment compression filter makes it really hard to post source code segments:
Object fridge "refrigerator" kitchen2
with
name 'fridge' 'refrigerator' 'kenmore' 'freezer',
description "It's a Kenmore combination refrigerator and freezer.
The front is covered with irrelevant notes from days gone by.",
before [;
Take: "Oh, you ", (pbold) "want", " a hernia?";
Open: if (cupboard hasnt general) {
give cupboard general;
"You open the refrigerator, but there's no light inside.
Suddenly, you realise that nothing in the house is running.
In your worry, you had neglected to notice that your music
had stopped playing. The refrigerator isn't even humming.
The power must be out. You reclose the refrigerator to
keep it from loosing its cool. The only sounds are coming
from the storm outside -- storm? There wasn't any storm
earlier.";
}
"You don't want to open the refrigerator with the power out; if
it gets too warm in there everything will spoil.";
],
has openable container scenery;
This is a simple object, a refrigerator. Other objects and code may refer to it as fridge. "refrigerator" is the hardwired short name, which is what it will be called when the game is talking to the player, in the absense of a short_name property. (Giving an object a short_name property allows you to do more complex things, like change the name in mid-game, determine the name each time on the fly with a routine, or cetera.) kitchen2 is the parent object, in this case the "room" where the refrigerator is located at the start of the game. (This particular object will _stay_ there, because the scenery attribute prevents the user from carting it around. Normally the static attribute is used for that, but scenery also prevents it from being mentioned automatically, which is useful for objects that you want to mention manually in room descriptions.) The name property contains dictionary words that the player may use to refer to the object; more complex objects can have a parse_name routine, but for the refrigerator the name property is good enough. The description property in this case is a string, though it could just as well be a routine; anyway, it's used when the user looks at the object. The before property holds a routine that gets a crack at doing whatever it wants just before an action happens, whenever the user attempts something with the object. In this case, if the user attempts to take the refrigerator the routine prints a snide remark (and, since it uses the implicit print_ret feature, it returns true, which prevents the action from taking place). If the user tries to open the refrigerator, an attribute on another object is tested, and an appropriate message is printed (again, using the implicit print_ret to return true and prevent the action). (What the cupboard object has to do with the player knowing the power is an interesting question; I don't remember, to tell the truth; this code is several years old, and I have barely looked at it ad interim.)
This is a very typical segment of code. With just a little practice, Inform code is very easy to read. The really great thing about Inform, though, is not the language itself, but the Designer's Manual. The DM *rocks*. It's one of the three or four best computer books I've ever read. Especially the section on the world model, with the Ruins example code. You can download it for free, or I suspect you can still get a print copy, though I've forgotten where. (Go to Google groups and ask on rec.arts.int-fiction and someone will know for sure.)
1. Get a Safari subscription from O'Reilly. 2. Spend an hour a day hanging out on Perlmonks.org or some similar place. 3. Find your niche. By this I mean figure out what software currently does
not exist or is inferior that you would use constantly, and then either
join or start a project to write the app.
Except you're going to have to do a db lookup anyway, to check for session expiration if nothing else.
> Of course if you stuff too much data in there it's gonna be slower (the > end user has to upload that fat cookie on every page request and your > server has to decrypt it).
I'd be more concerned about the other issues. If the cookie is just a unique number, you can tie it to a specific IP address much more easily. I suppose you could cryptographically sign the data with the IP address, but that's starting to get to be a pain and won't make debugging easy -- and then when the user has to redial and gets a new IP he can't just log in again and have all his data carry over.
Perhaps more significant, storing the data in the cookie (and, presumably, changing the cookie each time the data changes) is likely to have weird effects (read: bugs) when the browser starts doing wonky things with cookies, like sharing a cookie file between two browsers, limiting the max lifetime of cookies and dropping it before the server says it expires, forking the cookie jar when the browser opens one page in a new process and continues to use the other page in the other window, or who knows what. You could get back a perfectly valid cookie, in terms of the cryptographic signing, that nevertheless has old data because it's not the most recent one. This could create all kinds of havoc -- but if the cookie just identifies the user, then you don't have these issues; either the cookie is valid or not.
> Any http weenies out there know for sure if cookies are uploaded on all > get/post requests?
Only all requests with matching domain information. For example, a cookie issued by slashdot.org will be sent along with any requests going to slashdot.org (including apple.slashdot.org and other subdomains), but it will not be sent with requests to sourceforge.net for example.
> which means a page with a lot of images using fat cookies will seriously lag
A typical web page with a lot of images consists of enough bytes that it will dwarf the size of any but the most utterly extremely unreasonable uses of cookies, in terms of bandwidth. I suppose if it were storing something like which messages on a messageboard you'd read it could get that fat... but for normal amounts of data like your name and billing and shipping addresses and email and a couple of phone numbers and a dozen or so preferences and maybe a nickname and signature and your IP address and username and so on, a medium-sized image makes that all look like peanuts. It'd be, what, 2K? Nothing. I'd be more concerned about the security and privacy issues and general robustness.
> Does anyone seriously think Bill, Bush, Gore, Gates, Thatcher, Scott, Arnold, > etc. really have time to research and prepare up to a dozen dozen speeches > every week on topics ranging from youth education, the state of the automobile > industry, and how the new initiative will enhance health care in a region?
Shhh. Don't tell anyone that. By revealing that politicians don't write their own stuff, you take all the impact out of the "potatoe" incident, effectively taking away the strongest argument against Dan Quayle. If word of this gets out, and he ever runs again, he could be elected!
The public library where I work, for example, offers introductory classes, as
well as books and instructional videos. Some of my course materiels are
available here. A
public library where your mom lives might have similar programs; it's worth
checking. Also, school districts sometimes offer adult-ed programs that
might prove interesting.
Then there's usenet...
Of course hardware will be cheaper than it is now. Which is why we'll have more of it. Ten years ago we had one computer in my house, that's 1/5 of a computer per person. Today we have four in active use, 4/5 per person. In ten more years, we'll obviously have several systems per person. We'll want one in the bathroom, of course, because then I can read my email (or slashdot) in the tub, and we can replace all those stacks of old Reader's Digests on the back of the toilet, and so on. We'll want one in the kitchen for recipes, and so we can do stuff during the odd waiting times while cooking (e.g., read slashdot while the cookies are baking; leaving the room is impractical because you've only got three or four minutes, by the time you take the ones off the previous tray and rinse it off and put new doughballs on it for the next batch) -- plus of course some of our appliances will be computerized and probably networked. Eventually we'll replace the tv in the family room with a computer, I imagine. There are currently three computerless bedrooms; how long do you suppose that'll last? And so on.
But this is not news. We *know* hardware keeps getting cheaper; we've known it for thirty years or more. Everyone in the industry knows it, and a good many people who are not in the industry. It's not something I need a celebrity like Bill Gates to explain to me.
I used to watch it quite a bit when I was a kid, in the eighties, and I still watched some in the nineties too. I think I had myself convinced I was enjoying it, too, although honestly I can't remember a single thing I watched that I would now consider to be worth my time. At this point the last time I watched any was circa 2000 or maybe 2001.
What happens if you get a 1? Are you demoted, get your pay cut, or otherwise penalized? Or does your boss have to write some helpful suggestions on your review explaining things you can do to improve? In the former case, I'd be probably looking for ways to enhance my resume, but in the latter case I'd just ignore the ranking system entirely. (In my present job, we have annual employee reviews, but the only time I think about them is when I'm in the boss's office having my review. The rest of the time I just worry about doing my job.) Stuff like this can only demoralize you if you fret over it.
But yeah, if a low ranking has ramifications that matter, like demotion, then you should probably start looking for another job. Start looking now, because it can take a while to find one these days.
Isn't it considered to be better practice (in terms of security and privacy and all that jazz) to only use the cookie as a unique ID, an index into your DB table(s) containing all the other information? What is the advantage to storing more stuff on the client side?
> I know DOS is archaic but I still use it. It's useful for apps when you want > limited stuff in memory. Linux and windows can't compete with 100k kernal.
I don't mess with the embedded stuff. However, DOS has other uses too. I'm not talking about having it be my regular desktop system, but it has uses. Uses besides running legacy software, I mean. For one thing, it'll run on pretty much *any* x86 system, irrespective of the details of the hardware, and it has *no* trouble fitting on a floppy with plenty of room to spare for utilities (partitioning stuff, filesystem utils, hex editors, disk editors, whatever), and after it boots you can take out the boot floppy and just stick in a different floppy. DOS was made to run on systems with a 360K floppy drive (or worse) and it shows. If it happens to need (for reasons to do with memory managment, presumably) to reread something from the boot floppy again, it'll just prompt you to re-insert it, then prompt you again to put the other one back. This can get a little tedious, but it *works*, and it works under some pretty spartan conditions. (CD drive not working? Hard drive still need partitioning? No problem.) This makes DOS really great for things like setting up a blank partition table and installing a third-party bootloader (OS-BS or BOSS or PowerBoot or whatever).
DOS is also the preferred OS to use for flashing your BIOS or testing your hard drive for physical problems (especially if you only have one hard drive in the computer).
In the last few months Knoppix is *starting* to displace DOS for some of these things. Maybe eventually we'll be able to get by without DOS. But I'm not holding my breath.
> msdos really didnt multitask at all, unless the application you were > running would let you spawn off a shell.
MS-DOS offered _approximately_ the same level of multitasking as Windows 3.1 and MacOS 9. That is to say, there was no real multitasking at the OS level, but an application could be designed to multitask cooperatively, and there were various apps out there for DOS that were designed to do this, usually by hanging off the timer interrupt and only using a few cycles each time. Win3.1 and MacOS 9 may have provided facilities to make it easier for apps to do this, but the apps still had to go out of their way, so most apps didn't multitask in any meaningful sense; you could just switch between them, and the ones in the background would wait for you to switch back to them; this as task _swapping_, not multitasking, and MS-DOS had it as of 5.0.
There was also a third-party product designed to pre-emptively multitask ordinary DOS programs that weren't made for it. ISTR it was called MultiDOS Plus, but it wasn't a DOS replacement (though it might have replaced the command prompt; I don't recall for certain). It was pretty primitive: the user had to make decisions about timeslice sizes and things -- and on my (fairly old, even then) hardware, it wasn't practical. (Can you say "4.77 Megahertz?" I knew you could.) But it existed.
What was more *useful*, when it was added in DOS 5.0, is task swapping. This was provided through dosshell, and for running multiple DOS apps fullscreen and switching between them, it was every bit as good as Windows 3.1. I didn't switch to Windows for regular use until I got Windows 95, and then I only did it for the preemptive multitasking. (Shortly afterward, I started messing with Linux, and so of course now I'm a multibooting cross-platform geek.)
> drdos had 2 different multitasking options. i barely remember the > differences between them other than one would stop all other apps you had > open except for the one you were in currently, and the other would actually > give all the apps a slice of cpu time. this is if i am remembering correctly.
If you are remembering correctly, the first option is task _swapping_, which is not the same as multitasking. The second option describes multitasking.
Slashdot Mirror
> They need to work X hours at Y dollars an hour to achieve self-susteinance.
> With your plan, the employees make only half of what they used to.
You don't implement such a thing suddenly, cutting everybody's hours in half
overnight and hiring a bunch more half-timers to fill out the schedule. What
you do is, when you hire new "full-time" people (e.g. as a result of turnover),
you hire them for 30-35 hours, instead of 40. Also if possible you hire a
couple of part-timers for 20-25 hours. Then when you need to keep somebody
over past the scheduled end of their shift, you pick one of these people. In
time, you can convert your entire staff to being scheduled 30 or fewer hours
and actually working less than 40 almost 100% of the time.
Yes, *some* employees will be annoyed because they'll want 40 hours, and they
might even look for work elsewhere, but there are other people who will be
grateful not to be made to work overtime all the time because they prefer to
have some time left for other stuff. Six of one, half a dozen of the other,
but you can pay out less overtime this way, if that's your goal.
This does not, however, solve the scenerio where the higher-ups tell you to
run the place with less than such-and-such payroll.
When I worked at McDonald's, the system they used was to watch what payroll
was costing *as a percentage of gross* on an hour-by-hour basis. If it got
to be too high, they sent somebody home. This system had the advantage in
general of not sending home employees who were sorely needed to keep the
place running, because if we were busy then gross was high enough to support
more employees.
As far as I am aware (and I *think* I would have noticed, though it's hard
to be entirely certain), I have never seen time shaved per se at any place
where I've worked. I *have* seen all time rounded off to the nearest
quarter-hour, at places where timesheets are filled out with pen and paper
and the person doing payroll doesn't want to do complicated calculations.
But the employees did their own rounding. I'm not sure of the legality of
this arrangement (I suspect it's dubious at best), but it's not as near as
I can tell designed with the intention of cheating employees (if anything,
the employees could easily round up if it's even close); the goal is
simplification. I was always uncomfortable with it, though, and as I said
I'm unsure of the legality. I've also seen various other technically illegal
things...
I have seen a situation where "comp time" was heavily abused to shift time
from heavy weeks onto light weeks; I personally wouldn't have stood for it,
but the employee wasn't me but someone else I know, and he didn't even see
the problem when I explained it to him or seem to mind, so I let it go as
not my problem.
I've seen break times recorded as different from when the breaks were really
taken, to hide the fact that the employee worked more than five consecutive
hours between breaks. The employees did get the break, though, just not at
the time the records said. I've also seen employees voluntarily forego
breaks that _technically_ they legally have to have, and the employer
permitted it, which they legally aren't supposed to do. There was no
_pressure_ to forego breaks though, at least, nothing that could really be
construed as strong or direct pressure. (The place was busy and the other
employees busting themselves, and the person knew it, but nobody would have
objected if he took the break, and he knew that too. Call it pressure if
you want.) Again, this is definitely not legal, but it's also not quite
the same as the shaving discussed in the article.
I've seen (non-payroll) records falsified. I refused to participate, so
someone else did it. She was annoyed, but no action was taken against me.
I've seen managers instruct employees to do things that everyone present
knew was offi
> Are you suggesting all stores should hire 6-12+ people and simply keep them
> on retainer on the off chance that they're needed for those 2-4 hours a week
> most overtimes accrue to?
No, what you do is schedule your employees fewer than 40 hours. The ones who
insist they really need 40 hours, you give them 38-39 and make them leave on
time. If you need to keep somebody over, you don't take volunteers; you keep
somebody who only works 30-35 hours most weeks.
And yes, once in a while you'll have a situation where you really have no
choice but to give somebody overtime. But if it's happening on a weekly
basis, you've scheduled people too close to 40 hours and given up your
flexibility by doing so.
> can't remember a time when the Mac OS wasn't better than the comparable
:-)
> Windows version available at the time.
In all respects except maybe security, this is a pretty bogus claim. MacOS
was *different*, but it was not objectively *better* and in many ways was
a good deal *worse*. For example, Windows 95 OSR2 had real multitaking --
actual, factual, preemptive multitasking -- in 1996. MacOS didn't get it
until OS X came out. We're talking here about an important key feature
that *good* systems have had since the seventies: the ability for any
random application to be running at the same time as any other random
application, and the system doesn't freeze up for seconds-on-end while you
wait for something to finish; each application is responsive as if it were
running all the time (because, it is). So you can click on a link in Mozilla
and *immediately* switch to another window and do stuff while you wait for
the page to load. In MacOS 9.1, you can't do this; the browser monopolizes
the system, as if the whole OS were frozen up (in a sense, it is), waiting
for the page to load. This is a really big deal. It is, of course, fixed
in OS X. But Windows had this in late 1995 (sooner, if you count NT).
Then there's the dock. The Mac dock today (and since 10.0) is better than
anything Windows will have at least until Longhorn comes out[1], but prior
to that there was... there was... well, there was that little thing in the
upper-right-hand corner, a holdover from the System 6 Multifinder, that shows
which app is running, and you can pull it down and switch to a different one.
And the menubar at the top did have a clock. But there was nothing that
really could pass for an actual dock, bar, or panel.
Windows also has had, since 1995 or before, better memory management than
MacOS 9. This really shows up if you have more apps open than will fit in
RAM all at once. The classic Mac does not perform well under these
conditions; Windows 95 handles it much better; you only really notice the
swapping delays when you switch between applications. Additionally, Windows
95 does not require the user to configure VM manually, as MacOS 9 does.
(Windows 3.1 did require this; going to automatic handling of virtual
memory was a major leap forward in 1995.)
The Apple HIG is arguably better and certainly more closely followed by
most ISVs, but there are other niggly things about the Mac interface that
suck in ways that almost make up for that. With the Classic Mac you
basically *have* to have a third-party macro application, for example,
because way too few things have keyboard shortcuts. (The mouse is great
for discovering stuff you didn't know how to do, but it sucks for quickly
doing something that you do very frequently.) Keyboard shortcuts are much
more common in the Windows world (and almost totally universal in the *nix
world). OS X is starting to fix this (though there is still more to be done).
There are other things. To say that the MacOS is better than Windows *now*
is a fairly credible claim; to say that it has *always* been better than the
Windows available at the time is... bogus.
Although, in the Windows 3.1 days, I'd agree that the Mac system was better.
(I didn't use Windows much back then, though; I used DOS
[1] Gnome, however, is in some ways better. Notably, the applets are better,
and the Mac dock doesn't support drawers, which are IMO a killer feature.
The icon zooming on the Mac dock is better, however, and unifying the
running process list with the launchers, only listing a given app once
and indicating that it's running with the little arrow underneath, is a
nice touch. But the Windows taskbar is clearly inferior. But it was
better in 1995 than anything equivalent that the Mac had to offer until
OS X came out. It took Apple four or five years to catch on to this.
No, not everything, of course. But some of what he says is right. Much of
the bits about isolation and resiliency are dead on the money: having the
firewall on by default is a start, but if I understand correctly what he's
saying (which is hard, because the wording is brief and nontechnical; it
was obviously not written for a technically-inclined audience), Microsoft
intends to actually *fix* Outlook. Not "patch" it to stop a particular
exploit, but actually fix the root problem.
He also says some stuff that's good to hear despite not really constituting
security -- e.g., popup blocking, and not loading remote content in email.
He also talks about taking measures at the system level to mitigate the risk
of buffer overruns, but I can't tell from what he says whether what they're
doing there will be helpful or a placebo. This is where the CPU NX stuff
comes in, and I'm a little over my head there; I understand the idea, but
I don't think I grok all of the implications.
This is actually a good article. Not perfect, but good. Go read it, those
of you who haven't yet. I don't think we're going to slashdot Microsoft.
> For a lot of us, Mac OS 9 was really awful..
Really aweful doesn't even cover it. Windows 95 was really aweful. MacOS 9
(and earlier) was hideously and unforgivably Dain Brammaged. It's the only
OS I've seen that manages to combine worse error messages than DOS[1] with
worse memory management than Windows 3.1, while _claiming_ to have a great
GUI but not supporting such basic features as minimize and maximize, yet
also _claiming_ to support multitasking but in fact freezing up whenever
any app does anything. Classic can't die soon enough to suit me.
But note that I'm not anti-Apple anymore. Mac OS X is so much better than
MacOS 9, it's like the difference between night in a cave and noon on a
mountaintop. It's still not my favourite system, but it's a decent and
viable OS, and I feel good about calling it one of the "big three" (the
other two being Windows and *nix); before OS X, I cringed just thinking
about Mac being one of the big three system types.
[1] "Error: An error of type -876344 occurred." I've seen better error
messages written by high-school students the first week of BASIC class.
By comparison, "Error reading drive A: Abort, Retry, Ignore, Fail?"
is a veritable fountain of information about what the problem is and
what can be done about it.
> a number of !boot viruses, that could infect your machine even if you :-)
> just opened a filer view onto a floppy. Not even Windows can do that
Actually, Windows _can_ do that with CDs, unless you use TweakUI or regedit
to turn off the AutoPlay "feature". This was less of a problem when CD
burners were cost-prohibitive for most users, because people who caught
anything this way couldn't spread it around, since they didn't have a
burner. It worries me now, with burners being common these days. I always
turn AutoPlay off on Windows systems that I administer.
> So does having real division rather than floor division by default.
I think BASIC has real division by default, except of course that it's limited
by whatever data type you're working with. What I really want (and we're
*hopefully* getting it in Perl6) is numbers that automatically promote
themselves to bignums if necessary, so that there's no such thing as overflow.
Perl5 already promotes integers to floats as necessary, of course.
> And I believe its integer (no suffix) and double%, in BASIC
I'm pretty sure of integer%, since I used that quite a bit (in GWBASIC and
later QBasic). I'm a lot less sure about double, because I almost never did
anything in BASIC that needed floating point numbers.
Trivia point: in some implementions of BASIC, foo$ and foo% and so on are
all different variables, like @foo and %foo in Perl5. Use of this feature
is generally discouraged in beginning courses, however, since overuse of it
can create (minor) obfuscatory effects, _especially_ with overly laconic
variable names.
> A ground-breaking new game ported to OS X? Yeah, like anyone's going to
// series, ... you get the idea.
> believe THAT!
You display your ignorance. Anything written in Inform doesn't *have* to be
ported to OS X, or for that matter to any other platform. Inform compiles to
zcode, which is the second-most-portable format after 7-bit ASCII text. (Or
*possibly* third after HTML3.2, but that's debatable.) The format was
designed by Infocom so that they wouldn't have to create different versions
of their games (starting with zork) for each different platform they wanted
to release on. There are z-machine emulators (known in the interactive
fiction community as "interpreters") available for hundreds of platforms,
platforms you've never heard of. The guy who wrote Inform uses something
called Archimedes which runs on a hardware architecture called Acorn, for
example. Other supported platforms include the TRS-80, tenex, Gameboy, the
BBC Micro, Emacs, Mozilla (yes, there's a Firefox extension), Apple
IBM mainframes, the Java VM (yeah, a vm inside a vm),
Runs On Everything. zcode is supported on more platforms than GIF and JPG,
because almost a third of the platforms it runs on don't have graphics.
For OS X you have your choice of several dozen emulators ("interpreters"),
the most popular ones being MaxZip (native to MacOS, been around forever,
way before OS X) and frotz (for either Terminal.app or X11 if you get
Apple's X server, also been around forever but more cross-platform).
The user does have to download an emulator ("interpreter") though. If your
platform is at all common you can get one from ifarchive.org for example.
> You could try teaching them LOGO or lisp, but lisp is boring
...)
So go for a variant, like elisp or Scheme. elisp has the advantage of
being immediately useful, because you give them Emacs to use as an editor,
and the first thing everyone needs to do is change the keybindings, so
you teach them enough lisp to do that, and then you introduce them to some
other thing they'll want to customize, and teach them enough more lisp to
do that... pretty soon you've got them writing their own major modes and
talking about wishing Emacs supported forking or threading, at which point
you can introduce them to Scheme and start warp^H^H^H^Hstretching their
minds around concepts like continuations.
I prefer Perl, though. Yeah, it's case-sensitive, but you just teach them
to do everything in lowercase except for filehandles (uppercase) and modules
(usually Title::Case::Like::This, but however it's listed on search.cpan.org).
And yeah, there's more to learn in Perl than BASIC, but if you skip all the
functionality that's just plain _missing_ in BASIC (regexes, lexical and
dynamic scoping, packages and modules (except core pragmas, which correspond
roughly to the OPTION statement in BASIC), references, list transformations
like map and grep, formats (who uses those anyway?), printf and sprintf, most
of the special variables, typeglobs, the functional paradigm, objects,
then there's not nearly as much to teach 'em as there would be if you had
to teach the whole language. The only major concept you really *have* to
cover that's not present in BASIC is context. (Sigils actually have an
analog in BASIC, though in BASIC they're a suffix rather than a prefix and
the types are broken down differently, but it's the same basic idea,
string$, integer%, single! and double# (did I reverse those? It's been so
long...), and long&, verses $scalar, @array, %hash, &code, and *glob. As
mentioned, you don't have to cover typeglobs, and you don't really need to
cover coderefs either, so the & sigil can be skipped in a beginner course,
leaving only three, comparable to the big three ($, %, and one of the float
types, take your pick) for BASIC.)
If I wanted to do a beginner course in object-oriented programming, I'd use
Inform, on the grounds that virtually everyone with even slight geekish
tendencies can get "into" the problem domain it's intended to solve, and
also because the Designer's Manual is superb, and because its object model
is fairly complete, with a full object forest, nested inheritance,
multi-inheritance, easy instance objects (i.e., overriding inherited stuff
on a per-object basis) -- all the goodies. Also, Inform is very easy to
learn, and it's especially easy to read. It's not general-purpose at all,
but for learning OO concepts that doesn't matter.
> > Isn't it about time we ditched 20-year-old TV sets for something better?
> New TVs, available at your local stores.
Umm... isn't it about time we ditched the whole _concept of TV for something
better? Oh, wait... some of us already have, and it's called the _internet_.
> > Isn't it about time we ditched COBOL for something better?
> Visual Basic.
Wow. I have, umm, mixed feelings about whether VB is better than COBOL. I
mean, I took a COBOL class in college, and it was, like, bad, but then, I
also took a VB class, and it was, like, bad...
> > Isn't it about time we ditched BASIC for something better?
> Uhm... it's for beginners. We can't ditch the biginners...
There are other languages for beginners. Not that BASIC as really bad per
se (hey, I learned to program using BASIC...), but it's not the only option.
> > Isn't it about time we ditched Dubya for something better?
> John Kerry
Ugh. Can't the Dems do better than him? (Okay, so he seems more alive
than Gore, so I guess that could count as an improvement...)
My dad thinks the Dems deliberately avoided putting any viable candidate on
their ticket this time, because they want Bush to win so they can run Hillary
next time against Cheney. He says they figured running her against Bush would
be too risky, she might lose, and it would poison her career. Well, that's
what my dad says. Maybe he's finally lost it, I don't know, he is starting
to get old... but I've heard much crazier theories.
> ...mirrors would need to be in sync at all times for this to work.
This could be solved with versioning, as long as any given file is always
seeded/uploaded on the same server initially (say, on the server of the
person who is publishing the file).
Well, there's Net::BitTorrent::File, but this seems to be for use on the distribution end. Presumably the client would be Net::BitTorrent::Client, but that doesn't seem to exist yet. But BitTorrent has only really just started to catch on big-time in the last few months, so I'm sure someone will get to it before too long. A Mozilla plugin sounds like a good idea too, but that might be longer in coming.
Once a month I have to go to the bank and deposit my paycheck, lest I run out
of usable funds. Fortunately the bank is right nextdoor to where I work, so
I generally can just leave for work five minutes early and go to the bank on
the way, so it only adds a couple of minutes to my total time outdoors for the
month. Also any time I want to mail something (like, say, the checks to pay
my phone bill and ISP once a month) I have to go to the post office. But
fortunately the post office is just across the street from the bank, so I
usually go when I go to the bank, and just leave another five minutes earlier,
only adding another couple of minutes to my total time outdoors for the month.
If I have to buy stamps, I do that at the same time.
No, I'm not joking. The above is all true. Okay, I'm joking a little in that
the above reasons are not the *only* times I get out. I also go to church,
and occasionally I go to the hardware store (one block past the post office)
or some other place. Once in a great while (read: several years) I take the
dog for a nice long walk (read: several hours at one go) on a day off, just
because. Also occasionally I go for a walk by myself for a while, just
because. Usually I do this at an odd time, like the middle of the night,
when nobody's out. (I live in a relatively small community; at 3am you can
cross the biggest streets in town at your leisure without looking.) That's
my favourite time to go for a walk, because I can think out loud, wave my
arms around, gesturing to myself or an imagined audience, and just generally
do stuff that's only kosher to do in our society when you're alone, stuff
that gets me funny looks even from my immediate family -- but sometimes it's
nice to be able to cut loose like that someplace where you've got plenty of
room to walk around, such as outside.
Hmmm...., what's that? Oh yeah? Define "crazy".
> People jokingly announce really cool things that have no chance in hell of
> ever coming out.
I know. I'm still bummed about the George Foreman USB iGrill, too.
It's interesting, though, that the interactive fiction community (see for
example rec.arts.int-fiction on usenet) has a history of announcing really
cool things on April 1 that _were_ real. Okay, RAIF-POOL wasn't real, but
glulx was announced on April 1, and I'm thinking that either Inform version
6 or the Designer's Manual version 4 was announced on April 1 too. Also,
the community's number one vaporware product of all time, Avalon, when it
was finally actually released (albeit not under the original name; I now
forget the name it was released under) was announced on April 1. Or maybe
it was when it was made available for free download. Anyway, it was a
long-standing joke and much-desired event and when it finally happened for
real it was announced on April 1. Pretty decent game, too.
Here's an actual snippet, taken from a game I was working on years ago.
Sorry about the thin-to-nonexistant indentation, but the postercomment
compression filter makes it really hard to post source code segments:
Object fridge "refrigerator" kitchen2
with
name 'fridge' 'refrigerator' 'kenmore' 'freezer',
description "It's a Kenmore combination refrigerator and freezer.
The front is covered with irrelevant notes from days gone by.",
before [;
Take: "Oh, you ", (pbold) "want", " a hernia?";
Open: if (cupboard hasnt general) {
give cupboard general;
"You open the refrigerator, but there's no light inside.
Suddenly, you realise that nothing in the house is running.
In your worry, you had neglected to notice that your music
had stopped playing. The refrigerator isn't even humming.
The power must be out. You reclose the refrigerator to
keep it from loosing its cool. The only sounds are coming
from the storm outside -- storm? There wasn't any storm
earlier.";
}
"You don't want to open the refrigerator with the power out; if
it gets too warm in there everything will spoil.";
],
has openable container scenery;
This is a simple object, a refrigerator. Other objects and code may refer to
it as fridge. "refrigerator" is the hardwired short name, which is what it
will be called when the game is talking to the player, in the absense of a
short_name property. (Giving an object a short_name property allows you to
do more complex things, like change the name in mid-game, determine the name
each time on the fly with a routine, or cetera.) kitchen2 is the parent
object, in this case the "room" where the refrigerator is located at the
start of the game. (This particular object will _stay_ there, because the
scenery attribute prevents the user from carting it around. Normally the
static attribute is used for that, but scenery also prevents it from being
mentioned automatically, which is useful for objects that you want to mention
manually in room descriptions.) The name property contains dictionary words
that the player may use to refer to the object; more complex objects can have
a parse_name routine, but for the refrigerator the name property is good
enough. The description property in this case is a string, though it could
just as well be a routine; anyway, it's used when the user looks at the
object. The before property holds a routine that gets a crack at doing
whatever it wants just before an action happens, whenever the user attempts
something with the object. In this case, if the user attempts to take the
refrigerator the routine prints a snide remark (and, since it uses the
implicit print_ret feature, it returns true, which prevents the action from
taking place). If the user tries to open the refrigerator, an attribute on
another object is tested, and an appropriate message is printed (again, using
the implicit print_ret to return true and prevent the action). (What the
cupboard object has to do with the player knowing the power is an interesting
question; I don't remember, to tell the truth; this code is several years old,
and I have barely looked at it ad interim.)
This is a very typical segment of code. With just a little practice, Inform
code is very easy to read. The really great thing about Inform, though, is
not the language itself, but the Designer's Manual. The DM *rocks*. It's
one of the three or four best computer books I've ever read. Especially the
section on the world model, with the Ruins example code. You can download
it for free, or I suspect you can still get a print copy, though I've
forgotten where. (Go to Google groups and ask on rec.arts.int-fiction
and someone will know for sure.)
1. Get a Safari subscription from O'Reilly.
2. Spend an hour a day hanging out on Perlmonks.org or some similar place.
3. Find your niche. By this I mean figure out what software currently does
not exist or is inferior that you would use constantly, and then either
join or start a project to write the app.
> To avoid an extra database lookup.
Except you're going to have to do a db lookup anyway, to check for session
expiration if nothing else.
> Of course if you stuff too much data in there it's gonna be slower (the
> end user has to upload that fat cookie on every page request and your
> server has to decrypt it).
I'd be more concerned about the other issues. If the cookie is just a
unique number, you can tie it to a specific IP address much more easily.
I suppose you could cryptographically sign the data with the IP address,
but that's starting to get to be a pain and won't make debugging easy --
and then when the user has to redial and gets a new IP he can't just log
in again and have all his data carry over.
Perhaps more significant, storing the data in the cookie (and, presumably,
changing the cookie each time the data changes) is likely to have weird
effects (read: bugs) when the browser starts doing wonky things with cookies,
like sharing a cookie file between two browsers, limiting the max lifetime
of cookies and dropping it before the server says it expires, forking the
cookie jar when the browser opens one page in a new process and continues
to use the other page in the other window, or who knows what. You could
get back a perfectly valid cookie, in terms of the cryptographic signing,
that nevertheless has old data because it's not the most recent one. This
could create all kinds of havoc -- but if the cookie just identifies the
user, then you don't have these issues; either the cookie is valid or not.
> Any http weenies out there know for sure if cookies are uploaded on all
> get/post requests?
Only all requests with matching domain information. For example, a cookie
issued by slashdot.org will be sent along with any requests going to
slashdot.org (including apple.slashdot.org and other subdomains), but
it will not be sent with requests to sourceforge.net for example.
> which means a page with a lot of images using fat cookies will seriously lag
A typical web page with a lot of images consists of enough bytes that it will
dwarf the size of any but the most utterly extremely unreasonable uses of
cookies, in terms of bandwidth. I suppose if it were storing something like
which messages on a messageboard you'd read it could get that fat... but
for normal amounts of data like your name and billing and shipping addresses
and email and a couple of phone numbers and a dozen or so preferences and
maybe a nickname and signature and your IP address and username and so on,
a medium-sized image makes that all look like peanuts. It'd be, what, 2K?
Nothing. I'd be more concerned about the security and privacy issues and
general robustness.
> Does anyone seriously think Bill, Bush, Gore, Gates, Thatcher, Scott, Arnold,
> etc. really have time to research and prepare up to a dozen dozen speeches
> every week on topics ranging from youth education, the state of the automobile
> industry, and how the new initiative will enhance health care in a region?
Shhh. Don't tell anyone that. By revealing that politicians don't write their
own stuff, you take all the impact out of the "potatoe" incident, effectively
taking away the strongest argument against Dan Quayle. If word of this gets
out, and he ever runs again, he could be elected!
The public library where I work, for example, offers introductory classes, as well as books and instructional videos. Some of my course materiels are available here. A public library where your mom lives might have similar programs; it's worth checking. Also, school districts sometimes offer adult-ed programs that might prove interesting. Then there's usenet...
Of course hardware will be cheaper than it is now. Which is why we'll have
more of it. Ten years ago we had one computer in my house, that's 1/5 of a
computer per person. Today we have four in active use, 4/5 per person. In
ten more years, we'll obviously have several systems per person. We'll want
one in the bathroom, of course, because then I can read my email (or slashdot)
in the tub, and we can replace all those stacks of old Reader's Digests on
the back of the toilet, and so on. We'll want one in the kitchen for recipes,
and so we can do stuff during the odd waiting times while cooking (e.g.,
read slashdot while the cookies are baking; leaving the room is impractical
because you've only got three or four minutes, by the time you take the ones
off the previous tray and rinse it off and put new doughballs on it for the
next batch) -- plus of course some of our appliances will be computerized and
probably networked. Eventually we'll replace the tv in the family room with
a computer, I imagine. There are currently three computerless bedrooms; how
long do you suppose that'll last? And so on.
But this is not news. We *know* hardware keeps getting cheaper; we've known
it for thirty years or more. Everyone in the industry knows it, and a good
many people who are not in the industry. It's not something I need a
celebrity like Bill Gates to explain to me.
I used to watch it quite a bit when I was a kid, in the eighties, and I still
watched some in the nineties too. I think I had myself convinced I was
enjoying it, too, although honestly I can't remember a single thing I watched
that I would now consider to be worth my time. At this point the last time
I watched any was circa 2000 or maybe 2001.
What happens if you get a 1? Are you demoted, get your pay cut, or otherwise
penalized? Or does your boss have to write some helpful suggestions on your
review explaining things you can do to improve? In the former case, I'd be
probably looking for ways to enhance my resume, but in the latter case I'd
just ignore the ranking system entirely. (In my present job, we have annual
employee reviews, but the only time I think about them is when I'm in the
boss's office having my review. The rest of the time I just worry about doing
my job.) Stuff like this can only demoralize you if you fret over it.
But yeah, if a low ranking has ramifications that matter, like demotion, then
you should probably start looking for another job. Start looking now, because
it can take a while to find one these days.
Isn't it considered to be better practice (in terms of security and privacy and
all that jazz) to only use the cookie as a unique ID, an index into your DB
table(s) containing all the other information? What is the advantage to
storing more stuff on the client side?
> I know DOS is archaic but I still use it. It's useful for apps when you want
> limited stuff in memory. Linux and windows can't compete with 100k kernal.
I don't mess with the embedded stuff. However, DOS has other uses too. I'm
not talking about having it be my regular desktop system, but it has uses.
Uses besides running legacy software, I mean. For one thing, it'll run on
pretty much *any* x86 system, irrespective of the details of the hardware,
and it has *no* trouble fitting on a floppy with plenty of room to spare for
utilities (partitioning stuff, filesystem utils, hex editors, disk editors,
whatever), and after it boots you can take out the boot floppy and just stick
in a different floppy. DOS was made to run on systems with a 360K floppy
drive (or worse) and it shows. If it happens to need (for reasons to do
with memory managment, presumably) to reread something from the boot floppy
again, it'll just prompt you to re-insert it, then prompt you again to put
the other one back. This can get a little tedious, but it *works*, and it
works under some pretty spartan conditions. (CD drive not working? Hard
drive still need partitioning? No problem.) This makes DOS really great
for things like setting up a blank partition table and installing a
third-party bootloader (OS-BS or BOSS or PowerBoot or whatever).
DOS is also the preferred OS to use for flashing your BIOS or testing your
hard drive for physical problems (especially if you only have one hard drive
in the computer).
In the last few months Knoppix is *starting* to displace DOS for some of
these things. Maybe eventually we'll be able to get by without DOS. But
I'm not holding my breath.
> msdos really didnt multitask at all, unless the application you were
> running would let you spawn off a shell.
MS-DOS offered _approximately_ the same level of multitasking as Windows 3.1
and MacOS 9. That is to say, there was no real multitasking at the OS level,
but an application could be designed to multitask cooperatively, and there
were various apps out there for DOS that were designed to do this, usually
by hanging off the timer interrupt and only using a few cycles each time.
Win3.1 and MacOS 9 may have provided facilities to make it easier for apps
to do this, but the apps still had to go out of their way, so most apps
didn't multitask in any meaningful sense; you could just switch between them,
and the ones in the background would wait for you to switch back to them;
this as task _swapping_, not multitasking, and MS-DOS had it as of 5.0.
There was also a third-party product designed to pre-emptively multitask
ordinary DOS programs that weren't made for it. ISTR it was called MultiDOS
Plus, but it wasn't a DOS replacement (though it might have replaced the
command prompt; I don't recall for certain). It was pretty primitive: the
user had to make decisions about timeslice sizes and things -- and on my
(fairly old, even then) hardware, it wasn't practical. (Can you say "4.77
Megahertz?" I knew you could.) But it existed.
What was more *useful*, when it was added in DOS 5.0, is task swapping. This
was provided through dosshell, and for running multiple DOS apps fullscreen
and switching between them, it was every bit as good as Windows 3.1. I didn't
switch to Windows for regular use until I got Windows 95, and then I only did
it for the preemptive multitasking. (Shortly afterward, I started messing
with Linux, and so of course now I'm a multibooting cross-platform geek.)
> drdos had 2 different multitasking options. i barely remember the
> differences between them other than one would stop all other apps you had
> open except for the one you were in currently, and the other would actually
> give all the apps a slice of cpu time. this is if i am remembering correctly.
If you are remembering correctly, the first option is task _swapping_, which
is not the same as multitasking. The second option describes multitasking.