In Pittsburgh, where I am now, the local grocery market is such a depressing place that I'm shifting my grocery shopping to Wal-Mart. It's cheaper and service is actually friendlier.
At least a few years ago, the Giant Eagle in Squirrel Hill was pretty good . Of course, nothing beats going down to the strip district if you have the time.
Your comments are very nice, and maybe applicable in your work setting - but in most work settings (and I have been in a few) the bosses just say "hey we need you to work those extra hours. When review time comes, we will surely appreciate it. If you are not willing to work at least 50 hours a week, we can find someone to replace you."
In which case you say "sayonara, good luck finding a replacement".
I've yet to work at a company that could find enough good workers, or that was willing to alienate the ones it had.
And I really don't want to work for an employer who's going to take me for granted like that.
I mean, I've worked at big companies and small, private and government. I've found them all to be pretty flexible as long as your requests are reasonable--even negotiating points in the employment agreement and signing off on small modifications hasn't been a problem in my experience (I've yet to sign one as written). Even big legal departments can be reasonable if your requests are reasonable.
And it is not about being brave - it is about realizing you need a paycheck and the market may not be so hot (presently it takes about six months to find a new job, and that is not gauranteeing it will be any better)
Then you gotta suck it up while you job hunt. But you should be job hunting pronto, as soon as you realize your employer doesn't value you.
If you have a mac laying around try out Obj-C and the Cocoa libraries. They are not that far from what Smalltalk can do
I disagree, they have a couple of the less interesting smalltalk object-oriented features but they lack most of the things that make developing in Smalltalk fast, powerful, and easy.
If you're interested, download squeak (free) and give it a try. If you really must use something else, you're a lot closer to the Smalltalk experience if you work with Python than Cocoa.
The bug thing should not be an issue. It probably is though but that just means that Sun/IBM and anyone else with a Java implementation is not doing their job.
That's the core point of open-source, though. If Sun/IBM aren't doing their job, you have to plead with them or offer them enough money (at monopoly rates) to fix bugs. If it were open source, you could fix it yourself or pay someone else free-market rates to do so.
In particular, in an open-source project if there's a bug that's relatively minor overall but is a major problem for your project, you can fix it; such a bug is likely to be a very low priority for the developer of a closed-source project.
Uhh, if football were as simple as B it wouldn't be a problem. But it's a very rule-heavy game.
In baseball, if you understand the basics (balls, strikes, fouls, home runs, flys) then the only rules that really ever come up in "normal" play are the infield fly rule and the balk rule. Other rules address situations where the casual viewer is likely to say "that's odd, there must be a rule for that" -- ball bouncing out of play, beaning the batter, etc.
In football, on the other hand, if you understand the basics (TDs, field goals, downs, 2-point conversions, completions, fumbles) there are a ton of things that look like normal play but are governed by odd rules: ineligible receivers, illegal motion, completions without 2 feet in bounds, clipping, rules (clock management, fumbles, etc) changing randomly throughout the game or depending on the player (e.g. tackling the QB).
It's just not even close. I mean, how many times do you hear 2 friends who are regular football fans trying to clarify what the rules are and how they apply to the last play during the course of 1 game? And in baseball?
Identifying when baseball is exciting is not a trivial task, even for human cognitition. Trying to explain to a non-baseball-fan what's important about a given moment in baseball, is like trying to explain to a non-deadhead what was so great about one particular concert.
You can say the same about any sport. Unless you know what's going on, they all tend to be fairly boring.
I actually think baseball is easier for non-fans to watch than, say, football, which requires a fair amount of sophistication to follow at all even with all the efforts that go into play calling and technology to make it easier to watch (yellow down lines, etc).
In baseball, it's easier to start out focused on just one area (the pitch) and gradually start following defensive positioning, etc. And the slow pace of football is extremely frustrating to new viewers; the average NFL game is longer than the average MLB game, yet has only about half as many plays.
Now, once you get over the initial hump, the casual fan has more to watch in a football broadcast than a baseball broadcast. But I really do think that baseball is one of the easiest sports to start watching.
On the other hand, your pricing is way out of whack. We got a good 61" HDTV 2 years ago for right around $1600, and we've gotten at least 6 free HD channels (ABC, NBC, CBS, Fox, WB, PBS) over the air since inception. As of today we get at least 12 different HD channels either OTA or on basic digital cable.
Not cheap, sure, but nowhere near the price you're citing; for some people it's worth it rather than waiting 4 years to upgrade (2 years we've had it, plus another couple for this format war to play out). I'm pretty confident that we'll find a cheap solution for hooking up blu-ray or HDDVD when one of them wins the market.
apachectl graceful does the graceful restart that won't bring down other vhosts (and won't sever existing connections to the one that you're restarting).
apachectl restart will bring down other vhosts and sever connections (it's a hard reset)
If you don't like the apachectl program, well, just kill the top-level httpd with USR1 instead of KILL or TERM signal and it'll do the graceful restart (e.g. "kill -USR1 xxx" where xxx is the PID for the parent httpd).
I'm saying there are tons of benefits beyond speed
I've been waiting for solid-state drives to reach reasonable price ranges for years. Spinning platters are NOISY, they're the primary source of noise in my otherwise silent system.
There is minimal benefit to having it _AND_ magnetic media, as you might as well just load it up with RAM
OTOH, you might need a few hundred GB of storage that's infrequently accessed.
e.g. a music kiosk could store a huge library on magnetic disk, and spin it up only briefly to copy the next couple hours' songs over to SS storage.
Imagine how fast your database server would be with its transaction log installed in a memory file. Hey, throw the tempdb (for SQL Server) on there as well, or since the memory is now just standard memory and won't need a special driver, you can just switch to Linux and use a real database
There are certain benefits to having transaction logs in persistent storage. That's what this kind of drive buys you over memory (so for swap it makes no sense).
If you want to go to work an hour earlier, just go to work an hour earlier.
That would be nice if the other government rules and laws didn't mention time at all. But they do. In DC, they constrain when I can buy beer, play my radio audibly, ride the subway, etc. Changing DST has a real effect on those things.
A semi-modern PC has a minimum 40GB sized hard drive. And it only goes up from there. I've been online for quite sometime and while things have gotten MUCH better, with respect to bandwidth, it still takes a LONG, LONG, LONG time to transfer huge amounts of data. Note, I am not talking about your 4.5gig ISO image. I'm talking 20 of them. In a row.
Most businesses don't care about backing up all of your pr0n and music. For a lot of places, if you back up documents, email, and source code, you've got the core business stuff--and that's often fairly small. You do a full local backup of the servers, have a standard image of the desktops, then do web backups of a few directories nightly (e.g. all files on some samba share, a source repository, email). The web backups are rsync'd (or equivalent) so only the day's changes are transferred.
It's not ideal, but for a lot of places it works. Of course, they often find out after a crash that employees _weren't_ storing everything in "Work Documents" folder like they're supposed to.
For home use I usually just do hourly snapshots to another machine at home (I keep every hour for the last week, and the 4 previous weeks, and montly for 6 months, and then just yearly) with something like:
I'd love to see just some bullet points, like "Top 5 Reasons Smalltalk is Better than Java"
I wouldn't say it's necessarily better than Java. It's different. And it's pretty hard to describe--until you've worked in group environments on reasonably large projects, it's tough to get a feel for the benefits and drawbacks.
Basically, you gain a lot of flexibility and development speed working in Smalltalk (or Python, Ruby, Lisp, etc), but you need to be more careful about defining interfaces rigorously.
I've worked with both styles, and I'd say the static-typing way is better if you have a bunch of junior programmers implementing small modules with no real understanding for how the whole project works. If you have a group of relatively mature coders who have a decent understanding of when something is a horrible hack, then the dynamic way can yield a lot of benefits.
Smalltalk didn't catch on, not due to problems with dynamic typing, or the language itself, but mostly because of lack of availability...Sun released Java out to the public, and supported it documentation-wise. It allowed third party vendors to create compilers, and development environments, royalty free
I'm not sure I buy this explanation.
Freely available Smalltalk dev environments have been around for ages, long before the JDK (certainly the early 1990s, perhaps the late 1980s). Even Squeak goes back to about the same time as the JDK (1996). The Smalltalk language has been freely available for 3rd-party vendors, royalty free, for ages--IBM's VisualAge was originally a Smalltalk development environment, long before it was a Jave IDE.
Managers hate dynamic typing. They tend to believe that the gains from static typing are better for fast, stable development than the development pace gains you get in, say, Smalltalk, Lisp, or Python.
Bondage & Discipline. Used of languages that tend to enforce a particular programming style and particularly those that stress particular formalistic programming styles over real-world concerns. Java, ADA, and Pascal are classic examples.
...is the antithesis of the Java B&D philosophy. It's an aggressively dynamically typed language, and is much more of a precursor to Python or Ruby than Java.
the infrastructure costs (around $8million/mile) are similar to suburban road costs (about $5million/mile).
You're talking about increasing the single largest expense for most towns by 60%. How is that similar? What kind of town do you live in that can just throw away $3 million for every mile of road in the town?
And that's ignoring the fact that the roads are already built and you'd be building the new infrastructure from scratch. In the town I grew up in, assuming that you could sustainably increase the roads budget by an order of magnitude it'd by 30+ years before you finished the project--and that's assuming no ongoing maintenance/operational costs, and that you stop maintaining the existing roads entirely.
Slashdot Mirror
We can add that a credit card is necessary to travel.
What does this mean?
I've travelled post 9/11 by plane, bus, and train without a credit card.
As far as a job goes, the only things I've ever been asked for are SSN and proof of citizenship. Never a credit card, drivers license, etc.
In Pittsburgh, where I am now, the local grocery market is such a depressing place that I'm shifting my grocery shopping to Wal-Mart. It's cheaper and service is actually friendlier.
At least a few years ago, the Giant Eagle in Squirrel Hill was pretty good . Of course, nothing beats going down to the strip district if you have the time.
Your comments are very nice, and maybe applicable in your work setting - but in most work settings (and I have been in a few) the bosses just say "hey we need you to work those extra hours. When review time comes, we will surely appreciate it. If you are not willing to work at least 50 hours a week, we can find someone to replace you."
In which case you say "sayonara, good luck finding a replacement".
I've yet to work at a company that could find enough good workers, or that was willing to alienate the ones it had.
And I really don't want to work for an employer who's going to take me for granted like that.
I mean, I've worked at big companies and small, private and government. I've found them all to be pretty flexible as long as your requests are reasonable--even negotiating points in the employment agreement and signing off on small modifications hasn't been a problem in my experience (I've yet to sign one as written). Even big legal departments can be reasonable if your requests are reasonable.
And it is not about being brave - it is about realizing you need a paycheck and the market may not be so hot (presently it takes about six months to find a new job, and that is not gauranteeing it will be any better)
Then you gotta suck it up while you job hunt. But you should be job hunting pronto, as soon as you realize your employer doesn't value you.
If you have a mac laying around try out Obj-C and the Cocoa libraries. They are not that far from what Smalltalk can do
I disagree, they have a couple of the less interesting smalltalk object-oriented features but they lack most of the things that make developing in Smalltalk fast, powerful, and easy.
If you're interested, download squeak (free) and give it a try. If you really must use something else, you're a lot closer to the Smalltalk experience if you work with Python than Cocoa.
The bug thing should not be an issue. It probably is though but that just means that Sun/IBM and anyone else with a Java implementation is not doing their job.
That's the core point of open-source, though. If Sun/IBM aren't doing their job, you have to plead with them or offer them enough money (at monopoly rates) to fix bugs. If it were open source, you could fix it yourself or pay someone else free-market rates to do so.
In particular, in an open-source project if there's a bug that's relatively minor overall but is a major problem for your project, you can fix it; such a bug is likely to be a very low priority for the developer of a closed-source project.
Uhh, if football were as simple as B it wouldn't be a problem. But it's a very rule-heavy game.
In baseball, if you understand the basics (balls, strikes, fouls, home runs, flys) then the only rules that really ever come up in "normal" play are the infield fly rule and the balk rule. Other rules address situations where the casual viewer is likely to say "that's odd, there must be a rule for that" -- ball bouncing out of play, beaning the batter, etc.
In football, on the other hand, if you understand the basics (TDs, field goals, downs, 2-point conversions, completions, fumbles) there are a ton of things that look like normal play but are governed by odd rules: ineligible receivers, illegal motion, completions without 2 feet in bounds, clipping, rules (clock management, fumbles, etc) changing randomly throughout the game or depending on the player (e.g. tackling the QB).
It's just not even close. I mean, how many times do you hear 2 friends who are regular football fans trying to clarify what the rules are and how they apply to the last play during the course of 1 game? And in baseball?
Identifying when baseball is exciting is not a trivial task, even for human cognitition. Trying to explain to a non-baseball-fan what's important about a given moment in baseball, is like trying to explain to a non-deadhead what was so great about one particular concert.
You can say the same about any sport. Unless you know what's going on, they all tend to be fairly boring.
I actually think baseball is easier for non-fans to watch than, say, football, which requires a fair amount of sophistication to follow at all even with all the efforts that go into play calling and technology to make it easier to watch (yellow down lines, etc).
In baseball, it's easier to start out focused on just one area (the pitch) and gradually start following defensive positioning, etc. And the slow pace of football is extremely frustrating to new viewers; the average NFL game is longer than the average MLB game, yet has only about half as many plays.
Now, once you get over the initial hump, the casual fan has more to watch in a football broadcast than a baseball broadcast. But I really do think that baseball is one of the easiest sports to start watching.
The UNIX trademark is owned by the Open Group, not SCO.
http://www.unix.org/trademark.html
I can sort of see your point.
On the other hand, your pricing is way out of whack. We got a good 61" HDTV 2 years ago for right around $1600, and we've gotten at least 6 free HD channels (ABC, NBC, CBS, Fox, WB, PBS) over the air since inception. As of today we get at least 12 different HD channels either OTA or on basic digital cable.
Not cheap, sure, but nowhere near the price you're citing; for some people it's worth it rather than waiting 4 years to upgrade (2 years we've had it, plus another couple for this format war to play out). I'm pretty confident that we'll find a cheap solution for hooking up blu-ray or HDDVD when one of them wins the market.
It does, if you ask it to.
apachectl graceful does the graceful restart that won't bring down other vhosts (and won't sever existing connections to the one that you're restarting).
apachectl restart will bring down other vhosts and sever connections (it's a hard reset)
If you don't like the apachectl program, well, just kill the top-level httpd with USR1 instead of KILL or TERM signal and it'll do the graceful restart (e.g. "kill -USR1 xxx" where xxx is the PID for the parent httpd).
The contents will be lost a few hours after it loses power.
By which time in any high-availability system it'll have been backed up all the hell over the place.
I'm saying there are tons of benefits beyond speed
I've been waiting for solid-state drives to reach reasonable price ranges for years. Spinning platters are NOISY, they're the primary source of noise in my otherwise silent system.
There is minimal benefit to having it _AND_ magnetic media, as you might as well just load it up with RAM
OTOH, you might need a few hundred GB of storage that's infrequently accessed.
e.g. a music kiosk could store a huge library on magnetic disk, and spin it up only briefly to copy the next couple hours' songs over to SS storage.
Imagine how fast your database server would be with its transaction log installed in a memory file. Hey, throw the tempdb (for SQL Server) on there as well, or since the memory is now just standard memory and won't need a special driver, you can just switch to Linux and use a real database
There are certain benefits to having transaction logs in persistent storage. That's what this kind of drive buys you over memory (so for swap it makes no sense).
My thumb is very nearly one inch at its widest, thus solidifying the concept of a "rule of thumb"
I think the rule you're referring to is that it's about an inch from the tip of the thumb to the first joint--it's not related to width.
(presumably you're not referring to the old urban legend about beating wives...)
Are you going to finance extended Metro hours?
Do you really want to eliminate noise pollution and disturbing the peace laws?
If you want to go to work an hour earlier, just go to work an hour earlier.
That would be nice if the other government rules and laws didn't mention time at all. But they do. In DC, they constrain when I can buy beer, play my radio audibly, ride the subway, etc. Changing DST has a real effect on those things.
A semi-modern PC has a minimum 40GB sized hard drive. And it only goes up from there. I've been online for quite sometime and while things have gotten MUCH better, with respect to bandwidth, it still takes a LONG, LONG, LONG time to transfer huge amounts of data. Note, I am not talking about your 4.5gig ISO image. I'm talking 20 of them. In a row.
s /
Most businesses don't care about backing up all of your pr0n and music. For a lot of places, if you back up documents, email, and source code, you've got the core business stuff--and that's often fairly small. You do a full local backup of the servers, have a standard image of the desktops, then do web backups of a few directories nightly (e.g. all files on some samba share, a source repository, email). The web backups are rsync'd (or equivalent) so only the day's changes are transferred.
It's not ideal, but for a lot of places it works. Of course, they often find out after a crash that employees _weren't_ storing everything in "Work Documents" folder like they're supposed to.
For home use I usually just do hourly snapshots to another machine at home (I keep every hour for the last week, and the 4 previous weeks, and montly for 6 months, and then just yearly) with something like:
http://www.mikerubel.org/computers/rsync_snapshot
With nothing automated for off-site backups (though I do keep a handful of critical documents off-site by hand).
I cheat and do the initial rsync on local disk, only incremental stuff goes over the network.
I'd love to see just some bullet points, like "Top 5 Reasons Smalltalk is Better than Java"
I wouldn't say it's necessarily better than Java. It's different. And it's pretty hard to describe--until you've worked in group environments on reasonably large projects, it's tough to get a feel for the benefits and drawbacks.
Basically, you gain a lot of flexibility and development speed working in Smalltalk (or Python, Ruby, Lisp, etc), but you need to be more careful about defining interfaces rigorously.
I've worked with both styles, and I'd say the static-typing way is better if you have a bunch of junior programmers implementing small modules with no real understanding for how the whole project works. If you have a group of relatively mature coders who have a decent understanding of when something is a horrible hack, then the dynamic way can yield a lot of benefits.
Smalltalk didn't catch on, not due to problems with dynamic typing, or the language itself, but mostly because of lack of availability...Sun released Java out to the public, and supported it documentation-wise. It allowed third party vendors to create compilers, and development environments, royalty free
I'm not sure I buy this explanation.
Freely available Smalltalk dev environments have been around for ages, long before the JDK (certainly the early 1990s, perhaps the late 1980s). Even Squeak goes back to about the same time as the JDK (1996). The Smalltalk language has been freely available for 3rd-party vendors, royalty free, for ages--IBM's VisualAge was originally a Smalltalk development environment, long before it was a Jave IDE.
Managers hate dynamic typing. They tend to believe that the gains from static typing are better for fast, stable development than the development pace gains you get in, say, Smalltalk, Lisp, or Python.
Bondage & Discipline. Used of languages that tend to enforce a particular programming style and particularly those that stress particular formalistic programming styles over real-world concerns. Java, ADA, and Pascal are classic examples.
...is the antithesis of the Java B&D philosophy. It's an aggressively dynamically typed language, and is much more of a precursor to Python or Ruby than Java.
For many long sites, I do hit google and type in a couple keywords that I know will get me there through "I Feel Lucky".
Thankfully, I've only called 911 twice in the past 10 years
I wouldn't be too thankful--that's WAY above the average.
the infrastructure costs (around $8million/mile) are similar to suburban road costs (about $5million/mile).
You're talking about increasing the single largest expense for most towns by 60%. How is that similar? What kind of town do you live in that can just throw away $3 million for every mile of road in the town?
And that's ignoring the fact that the roads are already built and you'd be building the new infrastructure from scratch. In the town I grew up in, assuming that you could sustainably increase the roads budget by an order of magnitude it'd by 30+ years before you finished the project--and that's assuming no ongoing maintenance/operational costs, and that you stop maintaining the existing roads entirely.