years and years ago ('88/'89), some companies were trying to sell 300dpi monitors to the desktop publishing set. No one bought them, and they died. There's not much point in them now, given the wide-spread use of anti-aliasing.
I wonder how useful this will be for CAD - won't the thin lines be too difficult to see?
We ran PostgreSQL for quite a while, until
our performance needs caused us to choose
MySQL. I've not examined PostgreSQL in about
a year.
We've had one case of catastrophic data loss
on our old PostgreSQL database that we'd not
been able to diagnose (eg, the schema was
still intact, but all rows were zero'd).
Quoting a two-year-old article and holding it as representative of state-of-the-art is not generally a great idea.
MySQL 3.23, stable for some time now, is mostly robust - we've had it up on one server with a
load of 20 queries/second for over 300 days.
Stability under Linux 2.4.17 presently seems worse than
late 2.2.x kernels - see below.
Right now, lack of subselects is a pita but not unworkable. Table locking remains a major issue
when using MyISAM tables (as has been pointed out
innumerous times, InnoDB tables support row-level locking and transactions). There seem to be some optimizer issues for queries that use multiple indexes.
Personally, I'm trusting *my* benchmark. We've
got 20 quad-proc boxes running MySQL, with about
400GB of database. Now, this isn't record-setting
by any means, but we usually run our boxes at no more than 25% utilization to be able to accomodate "events" (twixt our two datacenters,
we aggregate around 50 million page turns a month , each page turn comprising multiple db queries.)
I would conclude that under Linux 2.4.17, quad-proc x86, MySQL runs very reasonably up to around 60-100 concurrent connections, after which stability is a bit shaky (we think this related to 2.4.17 SMP issues - we are anxious for 2.4.19 to test this theory). By "a bit shaky", I mean that the database server will crash. A watchdog script restarts the db server instantly - but at that point, we may have table corruption. Not a terribly good scenario that we (perhaps naively) believe transactions would largely solve.
Running with "low-priority-updates" has helped us scale quite a bit higher, but means when we do hit our threshold, things get ugly for a time.
The last thing I want is a bunch of namby-pamby feel-good coming my way. I've got a mostly thankless job, but it's not like I wasn't well aware of the nature of the beast.
My job is service. I fix problems. I don't feel my
job is particularly more stressful or thankless then, say, director of customer support, or a Tier 1 tech. If I'm doing my job well, I'm invisible. I'm paid well for being invisible.
Re:Biggest announcement? Ha!
on
.NET for Apache
·
· Score: 1
Nonsense.
Aunt Bea just isn't going to care, because it
doesn't solve any of her problems. Solutions
without real-world problems rarely find traction.
Web Services aren't about infrastructure any more
than HTML is. There was a good reason to come up
with the TABLE tag. There isn't a good reason for
Web Services.
What's a yambag?
Re:.net is not evil - just irrelevant
on
.NET for Apache
·
· Score: 1
I'm not calling you a heretic, but I'd dearly like
to understand why I would want to do any of the
things you describe:
Stock market. This and weather doohickies seem
to be the recipe programs of.net - that's about
all anyone can really think of to do with the
technology. Why would I want to have content
included from another site, that could argue
against my points? With dynamic content like
this, my discussion of the grim outlook of the stock market becomes confusing when the market turns bull.
Inclusion of content from other sites. Failure mode when site in question has been hacked? Is unreachable? My machine is experiencing networking problems? Remote server throwing internal server errors? Admin moves the page? Changes the content?
Read/Reply to Slashdot. I'm seriously trying to figure out why this is such a killer feature. Homogenize the web? Is that it? There should be
one set of interfaces for using the web? If so, we had that in Mosaic.9, and the market voted for chrome over content.
On one level, I can understand the point you're
making - but none of the arguments you present seem a particularly compelling reason to use the technology. Perhaps it's just the examples here.
Unfortunately, I think you presented the most lucid examples I've seen of why one might want to use.net - and it still sounds boring as hell.
Re:Biggest announcement? Ha!
on
.NET for Apache
·
· Score: 1
Read: Do consumers really want "Web Services"?
Any technology whose utility can't be readily
digested by the masses will fail. If you have
to explain to a significant non-zero portion
of tech-savvy slashdot users the value of a
technology, what are the odds Aunt Bea will
adopt it?
Or are you suggesting that the consumer will
reap the benefits without even realizing it?
Just like they reap the benefits of all those
Word features they never use?
It's discouraging that major infrastructure
pieces like XFree86 4.2.0 (out since January) failed
to make this release, yet candy like Gnome 1.4
made it. This was, in my opinion,
the first 4.x release that attained stability.
http://www.libpng.org/pub/png/#history
(By the way, despite the implications in some of CompuServe's old press releases and in occasional trade-press articles, PNG's development was not instigated by either CompuServe or the World Wide Web Consortium, nor was it led by them. Individuals from both organizations contributed to the effort, but the PNG development group exists as a separate, Internet-based entity.)
uh -- don't you say in one breath that
New York State is kicking in $200M, while
wondering what could have possessed the
companies to choose New York in the absence
of tax incentives or loan?
Just off the top-of-my-head, but don't you
think $200M is enough money to make YOUR
company open a research facility?
We run hosted web services for customers that
between two datacenters aggregate about 50 million
web hits a month.
Snort and logsurfer snippets from our firewall
logs go off all the time. Though I would say that
we have seen more attacks targeting linux services
(we're a linux shop, btw) than we've seen in the
past, the majority of our attacks do seem to be against windows-based services.
From an overall security point-of-view, the last
three to six months have not been great ones from
a linux vulnerability point-of-view: zlib, BIND,
ssh, apache, Tomcat (not that some of these problems haven't affected Windows boxen also). It's kept
us hopping patching our servers. We've been lucky, so far - no successful
intrusions (that we're aware of, of course!).
In general, it seems much easier to social
engineer one's way into a Windows network via
email attachments than directly attack it.
The problem is not losing the bandwidth - the much greater problem is losing their peering entry points into other networks. If from Lubbock, instead of connecting to an Austin, TX site through Dallas, you had to connect on a pipe through LA, do you think that might be noticeable? I think it could...
Losing a big chunk of the network is a big deal - just ask KPN/QWEST in Europe. I came into work this morning to find the peering points into AT in New York slammed as the transatlantic routes converged.
Re:linux (OT: 2.4 reliability)
on
Is Linux Dead?
·
· Score: 1
Finally, it hasn't helped that the last milestone release, 2.4, was a colossal mess. My 2.0.x and 2.2.x boxes were totally, utterly rock solid as servers. I upgraded one to 2.4 -- and it is now an unreliable piece of crap.
We've certainly seen reliability problems up until
recently. 2.4.17 has been working out well for us,
however, as web servers and back-end db servers
(+144 days for MySQL db servers doing about
75 queries/sec for the whole time).
2.4 definitely took a long time to stabilize,
but I think it's there (we have seen suspicious
ext3 problems even at 2.4.18 when using
data=writeback).
From a performance point of view, we've definitely seen more I/O throughput out of
2.4 - for MySQL, we're getting about 3 times
as many SQL queries handled, at less load.
Re:linux and the slow advance
on
Is Linux Dead?
·
· Score: 1
[putting on grumpy old man hat]
back in the day when printers were dangerous
to careless fingers and compiles were sometimes
measured in days, there used to be a great
community in which you could learn all manner
of coolness just by hanging around and keeping
alert.
Watching really competent people work is a great
way to learn your skill - like playing with really
good musicians, your ability will improve as you
learn all manner of cool tricks.
It used to be that you could learn a great deal
by building software. That can still be true, but
it's mostly now a./configure-and-forget kind of
world (building TeX from Knuth source is excruciatingly painful. TeTeX saved TeX from
self-immolation... but I digress).
A strong leader can (and should) be very
liberal with assigning projects that he knows
the victim is unfamiliar with. That sort of
where-do-I-begin anxiety usually leads to the
right sort of questions, and gets communication
flowing between your team members.
Having the same password on multiple machines is bad. Very bad
Okay, so what's your solution? I've got 3000
machines (hypothetical - I've only got a couple
hundred) - can I come up with a pattern I can
memorize that will allow for unique passwords
that require memorization of a base password and
some knowledge that lets me perturb the base?
I don't think so.
So what - only allow sudo? So I can run all the
rootly commands I want using - one password.
Carry them around encrypted in a PDA? Not much
confidence in the security that it seems most
encryptors use.
Unique passwords for this number of machines
do not fit in my head or my wallet. Use something
like S/key? Possibly...
The SunRays really are dumb terminals. No processing is performed in the client. It serves only as a conduit for sound, graphics, keyboard and mouse events. All processing is performed on a local centralized server. You seem to know this, so I'm not sure why you wouldn't call the SunRays dumb terminals.
That doesn't mean they aren't incredibly useful in certain environments.
How many of you have ever had to pay for an email which has been sent to you?
Just about everyone who's signed up with an ISP has
paid for email sent them. Oh, sure, not on a METERED
basis, but that's just because it's easier for the
ISPs to handle my monthly flat fee than to assess my
actual network usage.
...when viewed using a CRT (against their advice of using LCD for display), the samples appear as follows:
a) cleartype samples appear a bit sharper/darker than "traditional" anti-alias techniques, when viewed from monitor-eyeball distance. Closer inspection revealed some aliasing effects on the cleartype sample. b) cleartype looks just a hair better at small font sizes. c) the difference between cleartype and traditional anti-aliasing, on a CRT rather than an LCD, is pretty insignificant.
If I can get either of my laptops semi-reliable for more than a few minutes, I'll post some info on the difference. So far, my impression is that this is redundant technology that would mostly benefit Microsoft rather than the licensors of other anti-aliasing technology - perhaps the impetus for the creation of cleartype in the first place.
Sheesh, what a stink-up over simple Quality of Service issues. Excite@Home's going to end up ADDING a bunch of backbone bandwidth because of this - because they get paid more to do so.
Is Slashdot now reporting on rumors? The Mac rumor sites in particular have a lousy reputation for accuracy - how about reporting on news when it's news? Right now, it's just a bunch of folks saying, yeah, it'll happen, oh yeah, trust me.
Since WWDC is just a week away, why not resist and wait a week?
years and years ago ('88/'89), some companies
were trying to sell 300dpi monitors to the
desktop publishing set. No one bought them,
and they died. There's not much point in them
now, given the wide-spread use of anti-aliasing.
I wonder how useful this will be for CAD - won't
the thin lines be too difficult to see?
We've had one case of catastrophic data loss on our old PostgreSQL database that we'd not been able to diagnose (eg, the schema was still intact, but all rows were zero'd).
MySQL 3.23, stable for some time now, is mostly robust - we've had it up on one server with a load of 20 queries/second for over 300 days. Stability under Linux 2.4.17 presently seems worse than late 2.2.x kernels - see below.
Right now, lack of subselects is a pita but not unworkable. Table locking remains a major issue when using MyISAM tables (as has been pointed out innumerous times, InnoDB tables support row-level locking and transactions). There seem to be some optimizer issues for queries that use multiple indexes.
Personally, I'm trusting *my* benchmark. We've got 20 quad-proc boxes running MySQL, with about 400GB of database. Now, this isn't record-setting by any means, but we usually run our boxes at no more than 25% utilization to be able to accomodate "events" (twixt our two datacenters, we aggregate around 50 million page turns a month , each page turn comprising multiple db queries.)
I would conclude that under Linux 2.4.17, quad-proc x86, MySQL runs very reasonably up to around 60-100 concurrent connections, after which stability is a bit shaky (we think this related to 2.4.17 SMP issues - we are anxious for 2.4.19 to test this theory). By "a bit shaky", I mean that the database server will crash. A watchdog script restarts the db server instantly - but at that point, we may have table corruption. Not a terribly good scenario that we (perhaps naively) believe transactions would largely solve.
Running with "low-priority-updates" has helped us scale quite a bit higher, but means when we do hit our threshold, things get ugly for a time.
My job is service. I fix problems. I don't feel my job is particularly more stressful or thankless then, say, director of customer support, or a Tier 1 tech. If I'm doing my job well, I'm invisible. I'm paid well for being invisible.
Aunt Bea just isn't going to care, because it doesn't solve any of her problems. Solutions without real-world problems rarely find traction.
Web Services aren't about infrastructure any more than HTML is. There was a good reason to come up with the TABLE tag. There isn't a good reason for Web Services.
What's a yambag?
Stock market. This and weather doohickies seem to be the recipe programs of .net - that's about
all anyone can really think of to do with the
technology. Why would I want to have content
included from another site, that could argue
against my points? With dynamic content like
this, my discussion of the grim outlook of the stock market becomes confusing when the market turns bull.
Inclusion of content from other sites. Failure mode when site in question has been hacked? Is unreachable? My machine is experiencing networking problems? Remote server throwing internal server errors? Admin moves the page? Changes the content?
Read/Reply to Slashdot. I'm seriously trying to figure out why this is such a killer feature. Homogenize the web? Is that it? There should be one set of interfaces for using the web? If so, we had that in Mosaic .9, and the market voted for chrome over content.
On one level, I can understand the point you're making - but none of the arguments you present seem a particularly compelling reason to use the technology. Perhaps it's just the examples here. Unfortunately, I think you presented the most lucid examples I've seen of why one might want to use .net - and it still sounds boring as hell.
Do consumers really want "Web Services"?
Any technology whose utility can't be readily digested by the masses will fail. If you have to explain to a significant non-zero portion of tech-savvy slashdot users the value of a technology, what are the odds Aunt Bea will adopt it?
Or are you suggesting that the consumer will reap the benefits without even realizing it? Just like they reap the benefits of all those Word features they never use?
It's discouraging that major infrastructure pieces like XFree86 4.2.0 (out since January) failed to make this release, yet candy like Gnome 1.4 made it. This was, in my opinion, the first 4.x release that attained stability.
http://www.libpng.org/pub/png/#history (By the way, despite the implications in some of CompuServe's old press releases and in occasional trade-press articles, PNG's development was not instigated by either CompuServe or the World Wide Web Consortium, nor was it led by them. Individuals from both organizations contributed to the effort, but the PNG development group exists as a separate, Internet-based entity.)
Just off the top-of-my-head, but don't you think $200M is enough money to make YOUR company open a research facility?
Quite frankly, I do not believe you. Where are your sources for such a claim?
Snort and logsurfer snippets from our firewall logs go off all the time. Though I would say that we have seen more attacks targeting linux services (we're a linux shop, btw) than we've seen in the past, the majority of our attacks do seem to be against windows-based services.
From an overall security point-of-view, the last three to six months have not been great ones from a linux vulnerability point-of-view: zlib, BIND, ssh, apache, Tomcat (not that some of these problems haven't affected Windows boxen also). It's kept us hopping patching our servers. We've been lucky, so far - no successful intrusions (that we're aware of, of course!).
In general, it seems much easier to social engineer one's way into a Windows network via email attachments than directly attack it.
much greater problem is losing their peering
entry points into other networks. If from Lubbock, instead of connecting to an Austin, TX site through Dallas, you had to connect on a
pipe through LA, do you think that might be
noticeable? I think it could...
Losing a big chunk of the network is a big deal -
just ask KPN/QWEST in Europe. I came into work
this morning to find the peering points into
AT in New York slammed as the transatlantic routes converged.
We've certainly seen reliability problems up until recently. 2.4.17 has been working out well for us, however, as web servers and back-end db servers (+144 days for MySQL db servers doing about 75 queries/sec for the whole time).
2.4 definitely took a long time to stabilize, but I think it's there (we have seen suspicious ext3 problems even at 2.4.18 when using data=writeback).
From a performance point of view, we've definitely seen more I/O throughput out of 2.4 - for MySQL, we're getting about 3 times as many SQL queries handled, at less load.
Yeah, so you've been running a box that doesn't DO anything for a year (by your load average). Color me unimpressed.
Watching really competent people work is a great way to learn your skill - like playing with really good musicians, your ability will improve as you learn all manner of cool tricks.
It used to be that you could learn a great deal by building software. That can still be true, but it's mostly now a ./configure-and-forget kind of
world (building TeX from Knuth source is excruciatingly painful. TeTeX saved TeX from
self-immolation... but I digress).
A strong leader can (and should) be very liberal with assigning projects that he knows the victim is unfamiliar with. That sort of where-do-I-begin anxiety usually leads to the right sort of questions, and gets communication flowing between your team members.
Okay, so what's your solution? I've got 3000 machines (hypothetical - I've only got a couple hundred) - can I come up with a pattern I can memorize that will allow for unique passwords that require memorization of a base password and some knowledge that lets me perturb the base?
I don't think so.
So what - only allow sudo? So I can run all the rootly commands I want using - one password. Carry them around encrypted in a PDA? Not much confidence in the security that it seems most encryptors use.
Unique passwords for this number of machines do not fit in my head or my wallet. Use something like S/key? Possibly...
The SunRays really are dumb terminals. No
processing is performed in the client. It
serves only as a conduit for sound, graphics,
keyboard and mouse events. All processing is
performed on a local centralized server. You
seem to know this, so I'm not sure why you wouldn't
call the SunRays dumb terminals.
That doesn't mean they aren't incredibly useful
in certain environments.
I've found the easiest way to audit source is
grep for variants of open, creat, and exec. Not
fool-proof, but better than nothing.
Just about everyone who's signed up with an ISP has paid for email sent them. Oh, sure, not on a METERED basis, but that's just because it's easier for the ISPs to handle my monthly flat fee than to assess my actual network usage.
...as if TV had anything worthwhile to watch anyway.
Without the RDF of Linus on their staff, I doubt that Transmeta would have as much visibility as they do.
a) cleartype samples appear a bit sharper/darker than "traditional" anti-alias techniques, when viewed from monitor-eyeball distance. Closer inspection revealed some aliasing effects on the cleartype sample.
b) cleartype looks just a hair better at small font sizes.
c) the difference between cleartype and traditional anti-aliasing, on a CRT rather than an LCD, is pretty insignificant.
If I can get either of my laptops semi-reliable for more than a few minutes, I'll post some info on the difference. So far, my impression is that this is redundant technology that would mostly benefit Microsoft rather than the licensors of other anti-aliasing technology - perhaps the impetus for the creation of cleartype in the first place.
How this can be a bad thing is - well, confusing.
Since WWDC is just a week away, why not resist and wait a week?