so, what is the big deal with banning online gambling?
online gambling runs at roughly 12 billion dollars turnover per annum. serious, non-hyperbole analysts estimate that figure will raise to around 400 billion pa by 2014.
if you really seriously think morals play a role in any of this then well, please share some of that stuff you're smokin' there...
I'm not the same person but I can elaborate because we have also found bugs. The most serious so far has been that the semantics of resilvering a zfs mirror are well, questionable.
Imagine this scenario: One half of the mirror dies (e.g. hardware failure). You replace the failed device and put the mirror back online. ZFS will do a resilver and report the mirror as "online" and "healthy".
Sounds all good, right? Well, actually resilvering alone doesn't make the mirror redundant again! Pulling the plug of either side at that stage will trigger a nice kernel oops.
You have to perform a *scrub* on the pool to get full mirror redundancy back.
We're glad that we caught this during testing because it doesn't seem to be documented anywhere. Even the sun technician that handled our issue was pretty surprised.
Now one may argue that this is more a documentation bug than anything else, nonetheless we were told that sun considers to change the behaviour in a future patch. Not least because the zpool status output (remember: "healthy", "online") is strongly misleading. In fact, there doesn't seem to be a way to determine whether a "healthy" mirror is actually redundant (i.e. has been scrubbed, yet) or not. At least not with the standard CLI tools...
The workaround, for now, is to scrub your mirror after any changes - and ofcourse it doesn't hurt to do it regularly anyways.
Most of the other issues we had have fortunately been fixed with recent solaris-patches.
For example the dreaded SYNCHRONIZE CACHE issue that would kill performance on storage arrays with battery backed cache: http://blogs.digitar.com/jjww/?itemid=44
Well, in summary, we're quite happy with ZFS so far and it is maturing steadily. Just make sure to test it very thoroughly, especially corner cases and failure conditions, or you might cut yourself on one of few the remaining rough edges...
It is definately the most interesting choice for a filesystem nowadays. Although I'm eager to see what HAMMER will bring to the table...
When operating properly, the time interval between packet exchanges with the time servers is long so maintaining the equivalent of a TCP masquerading map isn't feasible (you either need unreasonably long timeouts leading to odd behavior when the entries become invalid but aren't timed-out, or you tend to time out active entries).
hmm, but doesn't ntp follow the same old request/response pattern? at least *my* ntp client has been working fine for ages with nothing but an old RELATED rule...
look at your/proc/net/ip_conntrack sometime and you'll notice it also tracks udp just fine.
It's all about the vision. And the people in charge. Just compare Steve Jobs to Steve Ballmer (or Billy, fwiw).
Which of these personalities do you think is more likely to design an OS that you would like?
Ofcourse it doesn't boil down to individuals but looking at the heads of a company gives you a good idea of the companies mindset.
Apple is "cool and hip" because the people working there *know* what "cool and hip" is.
Microsoft is not cool and hip because, well, it is driven by people like Steve Ballmer.
The sheer headcount, on the other hand, means nothing in the world of software developement. Small and well focussed (on the right goals) teams will outperform large teams everytime.
You can read up on that in "the mythical man month" and just about any other ressource about project management in the software industry.
In fact, developing "good" software (by any metrics) becomes much harder the larger your team gets. Programming is not like selling cars. It's more comparable to an orchestra. More instrumentalists don't necessarily improve the result but definately increase the effort to manage them.
We're doing a release (deploy) every day. Well, it's "only" updates to a website but nonetheless there's no way in hell to get any proper testing done at that rate.
Ofcourse it shows, we're late, down, overall broken all the time but our biz model basically involves a license to print money and so only very recently the metrics started to dive (market saturated, product quality begins to matter => oops!).
Well, even apart from all that I strongly believe that a functional team, led by a competent person, needs no XP books, "agile methologies" or any of that crap.
You don't build a team from a set of rules, those rules just come naturally when good people work together. Not to say that the XP/Agile manifestos are overall bad, but unless most of these rules were no-brainers in first place then no book in the world will help to fix your team anyways.
By my expirience most people who read (or even cite) such books merely use the new-learned buzzwords to augment their arsenal of excuses while still repeating the same mistakes over and over.
It's the kind of people who spend more time thinking about how to sell(/excuse) their failed projects towards their superiors than on trying to solve the task at hand.
It's the kind of assholes who stick to their paycheck despite having obviously realized long ago that they, themselves are the undeniable root cause of all the misery.
Speaking from 8yrs of expirience. Your mileage may vary.
Seconded! Make it a standalone box or just build it into those $20 multi-purpose routers.
For $30 or even $40 a shot I would buy three for redundancy and it would still be the cheapest solution.
My only worries would be accuracy (do we get subsecond over radio?) and reliability (my radio clock has actually jumped a few hours forward a few times - due to signal noise
or hardware bug?).
That said, It seems to me like this particular problem is something that could affect any on-line 'bank' -- even a reputable one. It's sort of analagous to having your brick and motar bank shut down by flood, fire, earthquake, riots, power failure.
I wonder why you undermine your own argument with these last two sentences. As a matter of fact, the regulations for brick and mortar banks involve disaster resilience (normally through redundancy over at least two independent datacenters) and multiple levels of insurance.
I have no idea if paypal is held to these standards by law but the sheer mass of customer horror stories is enough to have me avoid paypal at all costs (pun intended).
Dude, he already did the math for you and you still don't get it? Hardware is cheaper than labor, by orders of magnitude.
In fact, when your hardware-costs begin to escalate then most of the time it is because you were cheap (read: shortsighted) on your labor in the past and your underqualified "write-you-many-lines-of-code-for-$50-an-hour" contractors left you with an app that scales like a lame donkey.
Btw, swapping disks and ensuring stability is called "regular maintenance" and you should have full-time staff or contracts for that. If the cost of swapping a few disks matters in your equation then you have much bigger problems.
How should future development efforts be prioritized?
I like to consider gimp a proof of concept. Back in the days it proved that free software is capable of creating something "similar to photoshop". Ugly, cumbersome, nobody really wants to use it but hey, image editing for $0 dollars!
Many years have passed since that time and the adoption rate of gimp should have told you by now that something very essential must be wrong (under the premise that you're targeting a mainstream audience and not some very special niche). If you were to track gimp usage by technical means you'd see that your "conversion rate" is abysmal. Just about every linux user out there has probably tried gimp - once or twice. I even know a few people who tried to use it for serious work - a few weeks before giving up.
And it's not like the basic wrongs hadn't been pointed out a trillion times over just about any communications device ever invented.
So, if today you still have to ask "what issues to address" then i don't think you'll be able to understand, much less fix them properly.
Maybe your idea of what GIMP should be like simply differs too much from what most (occassional and pro) users want out of an image editing tool. But hey, you are the creators and not obliged to anybody. So why not rather focus on the strengths and your vision of GIMP? Why try to fix "issues" that haven't bothered you and the regular GIMP users in all the years?
I doubt that you can turn GIMP into krita in reasonable time anyways, even if you wanted to. And that's what any kind of usability feedback would tell you to do (yup, in my dayjob I'm a fortune teller).
If you seriously want to open GIMP up for a broader audience I think I have a better idea, though. Make the UI customizable. Really customizable. As in, every single UI item such as toolbars, buttons and menus should be drag'n'droppable to any location (yes, even menu items to buttons and vice versa). Furthermore make all behaviours customizable, like whether to open new images in a window or tab, etc.
Then provide profiles (and heck, a repository for user customized profiles) that imitate the UIs of old-gimp, photoshop, paintshop, and so on. You get the idea.
What, GTK doesn't do that? Well, I didn't say it wouldn't be a shitload of work...;-)
People want things that work 100% and aren't going to like it much when the spend lots of money and can only be told that 98% of what they bought will work. And absolutely nothing can be done about it.
Hmm. Recheck your reality. By the overall quality, especially software-wise, of my last few cellphones (Ericcsson T68i, Siemens/BENQ EF81, Nokia N73) I can tell that most people have long been brainwashed into not complaining about all those little annoyances that sum up to this "2% lack of functionality" that you mention.
If people would actually complain then my T68i UI wouldn't have been slow as molasses, the EF81 wouldn't have been the piece-of-trash it was and my N73 wouldn't "crash sometimes when taking photos or just randomly".
This applies to pretty much every tech gadget that you can buy nowadays, with only very few notable exceptions like the ipod. I think this is a symptom of the "windows generation". Joe Sixpack simply doesn't get to expirience properly engineered hard- or software very often, consequently he doesn't expect much more than "almost working" from his hitech gadgets.
"Welcome to 2007 and thanks for beta-testing the product you paid for."
sometimes you just want to let someone else make sure everything's working so you can get back to work.
Well, I'd consider myself a "power user" (responsible for >60 linux workstations and 20 production servers) and my reason to switch to gentoo (about a year ago) was that this "someone else" didn't seem to exist in my world (debian, redhat, ubuntu, even had my share of suse *ugh*).
Things would usually fall apart when I needed a more recent version of a particular package than available in the distro repository or when I needed an "advanced" feature (ldap, kerberos or just friggin png support) that was for some reason blown in the distro packages.
Eventually it always came down to mixing in homegrown binaries or pkgs into the distro and the resulting mess would become less and less maintainable over time.
I like gentoo because, unlike my past expirience with most other distros, things actually work after emerging and because it's much easier and cleaner to work with (very) recent versions of software. I can easily blend even a cvs-snapshot of something into the system without worrying that it will break the next time $pkgtool decides to upgrade my glibc.
Thus my (personal) conclusion would be: gentoo can be a real timesaver if you know what you're doing.
And my suggestion to most people who break their gentoo boxes all the time: I have never done an emerge world on any of my hosts. And I can see no compelling reason why you'd ever want to do that.
Well, if there was a better, non-selfish solution then I'd use it. I can only repeat that I consider the impact neglible.
If you become victim of a joejob then your mailbox gets flooded with bounces of all variety anyways. It's not like it gets noticably better when you take the C-R notices out of the equation.
And generally it's quite easy to filter out irrelevant (and joejobbed) bounces, too. I simply drop all bounces that do not contain an e-mail address that I have previously sent mail to.
That way I still get C-R notices from others and bounces that I want to see but none of the cruft...
Obviously this doesn't solve the waste of bandwidth and it's in no way an "elegant" approach. But until something worthwhile gets implemented at the SMTP level (think web of trust or C-R at a lower level) I see no alternative to preserve my sanity.
I deal with 20-40 legit mails on a workday and don't even want to imagine having to do the "false positive/negative" dance around them...
My domain is used as the return address for a ton of spam. I literally receive backscatter by the thousands to the point where I simply filter at the server (CPanel) to delete (not merely send to a junk folder) all postmaster messages, all challenge response systems, all vacation autorespnders, etc. That cuts the junk for my bayesian filters to sort through down to a couple hundred messages a day.
Well, my little challenger doesn't make much of a difference really. Imagine everybody got rid of their challenge/response filters today. By what margin would that reduce your personal joejob-whiplash? Yep, thought so.
The problem is not caused or even significantly amplified by challenge-systems. They're just a very small part of the symptom.
Do the net a favor, and start obeying standards. They exist for a reason, I am surprised all the noise you create hasn't got your mail server listed in a few RBL's.
What standard are you referring to? The confirmation requests are plain old bounce notices (QSBMF). You could just as well be getting a "Mailbox full" or "Unknown user".
I basically say "fsck it, it ain't worth jumping through hoops to send a dang email".
Well, during the first months I was indeed worried to miss an "important" mail and skimmed the hold-queue occassionally. By now I'm cool, it has just never happened.
I don't receive many "important" cold contacts. In fact, nobody has ever tried to reach me by E-Mail to tell me that I won the lottery (sad enough!).
The normal case is that people either confirm their request once (and forget about it instantly) or that I initiated the contact and their domain gets added to my whitelist that way.
I have also configured my system quite generously which means that a confirmed address whitelists the whole domain. So if I correspond with companyA.com once then any employee of said company can reach me without confirmation from then on. I also made a small CGI so that people don't even have to reply but can whitelist themselves with a single mouseclick.
I can only talk about my personal expirience here and that was entirely painless. Yes, it needed some tweaking in the very beginning but since I added a very simple bounce filter (that only lets bounces through that contain an address that I have previously sent mail to) I have not seen a single spam and have never had to resurrect a false-positive.
Once you get over the fear to "miss something important" and invested some straightforward tweaking it's pretty much easy going...
I use qconfirm myself but there's also tmda and others. *If* you are serious about getting rid of the spam then just do it. The technical part is readily available.
I deployed that almost a year ago and never looked back. I still see the occassional spam in a mailing list folder because those go through unfiltered for obvious reasons but I couldn't care less. My inbox has been spam-free since then and that's what matters.
I don't quite get why people are still bothering with greylisting, spamassassin, razor, dcc, bayes and the ilk. I tried them all and they're more trouble than it's worth. You get false positives, false negatives, it's a stupid game that you can't win.
You are right if the server belongs to different realms (or even different customers). I was assuming that both servers were part of the same setup, i.e. webserver and db server.
In such a setup the machines usually need to trust each other anyways to a degree that it becomes nearly impossible to "insulate" them from each other. In that latter scenario an addtl serial link doesn't take away any security.
Ofcourse one should *never* wire up two servers of distinct customers that way!;-)
And lastly: Amarok. One question: does it come with Ubuntu -- or any distribution -- by default? Can you buy music with it? Can you sync your iPod or Zune with it? These are the things average users want.
Hey, no wonder you are posting as AC, given you have obviously never worked on a worthwhile dataset.
It is common practice to do bulk imports on a non-indexed table and create the index afterwards. It's done that way for the simple reason that bulk indexing is *much* faster than having the db do its index lookup/update magic for each insert.
Sure, there's no difference when you're dealing a few thousand rows. Nonetheless your statement shows that you've never tried it on a few million rows...
With the single DVD jukebox, the first 800GB is online at one time, for $450. A 750GB HD costs $350. But the next 800GB in DVD costs only $40 - each 4TB costs $200. And there's no limit to how many $50 TBs you can archive, with a sizeable enough closet. The downside is un/loading the jukebox, 200 at a time. But that's archive, "nearline" storage.
Hmm, where can I buy that $400 jukebox that will also write my DVDs? Because with a single writer (or even a bunch of them) writing 200 discs is quite a painful process. You're looking at 13hrs writing time and you can't go away because you have to babysit (swap disc, write label) every two minutes.
Unless you need fast random access to your archive then tape is still the way to go. A single AIT4-drive sets you back about $1500. Each tape holds 200G so you get 4 tapes instead of 200 discs. Quite a difference..
Agile programming means planning for things to change
You said:
This is completely wrong. Agile recognizes that change inevitably happens but that it is chaotic and unpredictable.
Well, what does it matter, imho this whole agile, XP stuff is made up by crackmonkeys anyways.
If you want to software that works then you need three things:
- One Architect (or a team that acts like one) - A bunch of highly skilled codemonkeys - A plan which is turned into a spec by the architect and which only changes around *pre-defined* joints
Most projects that I have encountered failed on all three of these points and tried to make up by going after "agile practices", standup meetings, pair programming and all that rubbish. And most of them didn't even notice that not even the best process (if its worth a damn) can make up for the lack of any of the above. Not a bit.
If you don't have an architect then you don't even have to start. Your software will be flawed from the getgo and the accumulating design failures will make your work slower and more expensive every day.
If you don't have good codemonkeys but rather buy three "fresh'outta'college" students for the price of one qualified hacker (cuz 3 for the price of one is a great deal, right??) then you're doomed for the architect either leaving early pissed or, worse, him sanctioning that kind of staffing due to a vested interest in a longer chain-of-blame (which tells you all about how good of a choice he was).
If you don't have a plan and stick to it then you're lost in either case. Software as flexible as a car that can be turned into a plane overnight is a pipe dream. You either know what you want to do or you don't. In the latter case you shouldn't even start either.
None of that can be fixed with any kind of process. Otoh, a qualified team already has or will quickly develop whatever process works best for them.
All this XP nonsense is made and picked up by the clueless PMs and PHBs crowd that's always in desperate need to justify their failure. Which is good. For the people who actually get work done. You spend your time on tweak, tune and blame the process. Meanwhile those with a clue just sit down and build youtube.
online gambling runs at roughly 12 billion dollars turnover per annum.
serious, non-hyperbole analysts estimate that figure will raise to around
400 billion pa by 2014.
if you really seriously think morals play a role in any of this
then well, please share some of that stuff you're smokin' there...
I'm not the same person but I can elaborate because we have also found bugs.
The most serious so far has been that the semantics of resilvering a zfs mirror
are well, questionable.
Imagine this scenario:
One half of the mirror dies (e.g. hardware failure).
You replace the failed device and put the mirror back online.
ZFS will do a resilver and report the mirror as "online" and
"healthy".
Sounds all good, right?
Well, actually resilvering alone doesn't make the mirror
redundant again! Pulling the plug of either side at
that stage will trigger a nice kernel oops.
You have to perform a *scrub* on the pool to get
full mirror redundancy back.
We're glad that we caught this during testing because
it doesn't seem to be documented anywhere. Even the
sun technician that handled our issue was pretty surprised.
Now one may argue that this is more a documentation bug than
anything else, nonetheless we were told that sun considers
to change the behaviour in a future patch. Not least because
the zpool status output (remember: "healthy", "online") is
strongly misleading. In fact, there doesn't seem to be a way
to determine whether a "healthy" mirror is actually redundant
(i.e. has been scrubbed, yet) or not. At least not
with the standard CLI tools...
The workaround, for now, is to scrub your mirror after
any changes - and ofcourse it doesn't hurt to do it
regularly anyways.
Most of the other issues we had have fortunately
been fixed with recent solaris-patches.
For example the dreaded SYNCHRONIZE CACHE issue that
would kill performance on storage arrays with
battery backed cache:
http://blogs.digitar.com/jjww/?itemid=44
Well, in summary, we're quite happy with ZFS so
far and it is maturing steadily. Just make sure
to test it very thoroughly, especially corner cases
and failure conditions, or you might cut yourself
on one of few the remaining rough edges...
It is definately the most interesting choice for a filesystem
nowadays. Although I'm eager to see what HAMMER will bring to
the table...
hmm, but doesn't ntp follow the same old request/response pattern?
at least *my* ntp client has been working fine for ages with nothing but an old RELATED rule...
look at your
It's all about the vision. And the people in charge.
Just compare Steve Jobs to Steve Ballmer (or Billy, fwiw).
Which of these personalities do you think is more
likely to design an OS that you would like?
Ofcourse it doesn't boil down to individuals but looking
at the heads of a company gives you a good idea of the
companies mindset.
Apple is "cool and hip" because the people working
there *know* what "cool and hip" is.
Microsoft is not cool and hip because, well, it is
driven by people like Steve Ballmer.
The sheer headcount, on the other hand, means
nothing in the world of software developement.
Small and well focussed (on the right goals)
teams will outperform large teams everytime.
You can read up on that in "the mythical man month"
and just about any other ressource about project
management in the software industry.
In fact, developing "good" software (by any metrics)
becomes much harder the larger your team gets.
Programming is not like selling cars. It's more
comparable to an orchestra. More instrumentalists
don't necessarily improve the result but definately
increase the effort to manage them.
A release every month?
Lucky bastard, hug your manglement from me.
We're doing a release (deploy) every day. Well, it's "only"
updates to a website but nonetheless there's no way in hell to
get any proper testing done at that rate.
Ofcourse it shows, we're late, down, overall broken all the time
but our biz model basically involves a license to print money and so
only very recently the metrics started to dive (market saturated, product
quality begins to matter => oops!).
Well, even apart from all that I strongly believe that a functional team,
led by a competent person, needs no XP books, "agile methologies" or any
of that crap.
You don't build a team from a set of rules, those rules just come
naturally when good people work together. Not to say that the XP/Agile
manifestos are overall bad, but unless most of these rules were no-brainers
in first place then no book in the world will help to fix your team anyways.
By my expirience most people who read (or even cite) such books
merely use the new-learned buzzwords to augment their arsenal of
excuses while still repeating the same mistakes over and over.
It's the kind of people who spend more time thinking about how
to sell(/excuse) their failed projects towards their superiors than
on trying to solve the task at hand.
It's the kind of assholes who stick to their paycheck
despite having obviously realized long ago that they, themselves
are the undeniable root cause of all the misery.
Speaking from 8yrs of expirience. Your mileage may vary.
Seconded!
Make it a standalone box or just build it into those $20 multi-purpose routers.
For $30 or even $40 a shot I would buy three for redundancy and it would still
be the cheapest solution.
My only worries would be accuracy (do we get subsecond over radio?) and reliability
(my radio clock has actually jumped a few hours forward a few times - due to signal noise
or hardware bug?).
I wonder why you undermine your own argument with these last two sentences.
As a matter of fact, the regulations for brick and mortar banks involve disaster resilience (normally through redundancy over at least two independent datacenters)
and multiple levels of insurance.
I have no idea if paypal is held to these standards by law but the sheer mass of customer horror stories is enough
to have me avoid paypal at all costs (pun intended).
Dude, he already did the math for you and you still don't get it?
Hardware is cheaper than labor, by orders of magnitude.
In fact, when your hardware-costs begin to escalate then most of the time it is because you were cheap (read: shortsighted)
on your labor in the past and your underqualified "write-you-many-lines-of-code-for-$50-an-hour" contractors
left you with an app that scales like a lame donkey.
Btw, swapping disks and ensuring stability is called "regular maintenance" and you should have
full-time staff or contracts for that. If the cost of swapping a few disks matters in your equation
then you have much bigger problems.
I like to consider gimp a proof of concept. Back in the days it proved that free software is capable of creating something "similar to photoshop".
Ugly, cumbersome, nobody really wants to use it but hey, image editing for $0 dollars!
Many years have passed since that time and the adoption rate of gimp should have told you by now that something very essential must be wrong (under the premise that you're targeting a mainstream audience and not some very special niche). If you were to track gimp usage by technical means you'd see that your "conversion rate" is abysmal. Just about every linux user out there has probably tried gimp - once or twice. I even know a few people who tried to use it for serious work - a few weeks before giving up.
And it's not like the basic wrongs hadn't been pointed out a trillion times over just about any communications device ever invented.
So, if today you still have to ask "what issues to address" then i don't think you'll be able to understand, much less fix them properly.
Maybe your idea of what GIMP should be like simply differs too much from what most (occassional and pro) users want out of an image editing tool.
But hey, you are the creators and not obliged to anybody. So why not rather focus on the strengths and your vision of GIMP?
Why try to fix "issues" that haven't bothered you and the regular GIMP users in all the years?
I doubt that you can turn GIMP into krita in reasonable time anyways, even if you wanted to.
And that's what any kind of usability feedback would tell you to do (yup, in my dayjob I'm a fortune teller).
If you seriously want to open GIMP up for a broader audience I think I have a better idea, though.
Make the UI customizable. Really customizable. As in, every single UI item such as toolbars, buttons
and menus should be drag'n'droppable to any location (yes, even menu items to buttons and vice versa).
Furthermore make all behaviours customizable, like whether to open new images in a window or tab, etc.
Then provide profiles (and heck, a repository for user customized profiles) that imitate the UIs of
old-gimp, photoshop, paintshop, and so on. You get the idea.
What, GTK doesn't do that? Well, I didn't say it wouldn't be a shitload of work...
Hmm. Recheck your reality.
By the overall quality, especially software-wise, of my last few cellphones (Ericcsson T68i, Siemens/BENQ EF81, Nokia N73) I can tell that most people have long been brainwashed into not complaining about all those little annoyances that sum up to this "2% lack of functionality" that you mention.
If people would actually complain then my T68i UI wouldn't have been slow as molasses, the EF81 wouldn't have been the piece-of-trash it was and my N73 wouldn't "crash sometimes when taking photos or just randomly".
This applies to pretty much every tech gadget that you can buy nowadays, with only very few notable exceptions like the ipod.
I think this is a symptom of the "windows generation". Joe Sixpack simply doesn't get to expirience properly engineered hard- or software very often, consequently he doesn't expect much more than "almost working" from his hitech gadgets.
"Welcome to 2007 and thanks for beta-testing the product you paid for."
Hm. Just curious but which specific packages were too out of date for you?
sometimes you just want to let someone else make sure everything's working so you can get back to work.
Well, I'd consider myself a "power user" (responsible for >60 linux workstations and 20 production servers)
and my reason to switch to gentoo (about a year ago) was that this "someone else" didn't seem to exist
in my world (debian, redhat, ubuntu, even had my share of suse *ugh*).
Things would usually fall apart when I needed a more recent version of a particular package than available
in the distro repository or when I needed an "advanced" feature (ldap, kerberos or just friggin png support)
that was for some reason blown in the distro packages.
Eventually it always came down to mixing in homegrown binaries or pkgs into the distro and the
resulting mess would become less and less maintainable over time.
I like gentoo because, unlike my past expirience with most other distros, things actually work after emerging
and because it's much easier and cleaner to work with (very) recent versions of software. I can easily blend
even a cvs-snapshot of something into the system without worrying that it will break the next time $pkgtool
decides to upgrade my glibc.
Thus my (personal) conclusion would be: gentoo can be a real timesaver if you know what you're doing.
And my suggestion to most people who break their gentoo boxes all the time:
I have never done an emerge world on any of my hosts. And I can see no compelling reason why you'd ever want to do that.
One word: Mantis. (be sure to look at the demo)
Well, if there was a better, non-selfish solution then I'd use it.
I can only repeat that I consider the impact neglible.
If you become victim of a joejob then your mailbox gets flooded with
bounces of all variety anyways. It's not like it gets noticably better when you
take the C-R notices out of the equation.
And generally it's quite easy to filter out irrelevant (and joejobbed) bounces, too.
I simply drop all bounces that do not contain an e-mail address that I have
previously sent mail to.
That way I still get C-R notices from others and bounces that I want
to see but none of the cruft...
Obviously this doesn't solve the waste of bandwidth and it's in no way an "elegant"
approach. But until something worthwhile gets implemented at the SMTP level (think web of
trust or C-R at a lower level) I see no alternative to preserve my sanity.
I deal with 20-40 legit mails on a workday and don't even want to imagine having to
do the "false positive/negative" dance around them...
Well, my little challenger doesn't make much of a difference really.
Imagine everybody got rid of their challenge/response filters today.
By what margin would that reduce your personal joejob-whiplash?
Yep, thought so.
The problem is not caused or even significantly amplified by challenge-systems.
They're just a very small part of the symptom.
What standard are you referring to?
The confirmation requests are plain old bounce notices (QSBMF).
You could just as well be getting a "Mailbox full" or "Unknown user".
Well, during the first months I was indeed worried to miss an "important" mail
and skimmed the hold-queue occassionally. By now I'm cool, it has just never happened.
I don't receive many "important" cold contacts. In fact, nobody has ever tried to reach
me by E-Mail to tell me that I won the lottery (sad enough!).
The normal case is that people either confirm their request once (and forget about it instantly)
or that I initiated the contact and their domain gets added to my whitelist that way.
I have also configured my system quite generously which means that a confirmed address
whitelists the whole domain. So if I correspond with companyA.com once then any employee
of said company can reach me without confirmation from then on.
I also made a small CGI so that people don't even have to reply but can whitelist themselves
with a single mouseclick.
I can only talk about my personal expirience here and that was entirely painless.
Yes, it needed some tweaking in the very beginning but since I added a very simple bounce
filter (that only lets bounces through that contain an address that I have previously sent
mail to) I have not seen a single spam and have never had to resurrect a false-positive.
Once you get over the fear to "miss something important" and invested some straightforward
tweaking it's pretty much easy going...
Yep. It was also used for SeaQuest and Babylon5.
Ah, the olden days...
I use qconfirm myself but there's also tmda and others.
*If* you are serious about getting rid of the spam then just do it. The technical part is readily available.
I deployed that almost a year ago and never looked back. I still see the occassional spam in a
mailing list folder because those go through unfiltered for obvious reasons but I couldn't care less.
My inbox has been spam-free since then and that's what matters.
I don't quite get why people are still bothering with greylisting, spamassassin, razor, dcc, bayes and
the ilk. I tried them all and they're more trouble than it's worth. You get false positives, false negatives,
it's a stupid game that you can't win.
You are right if the server belongs to different realms (or even different customers).
;-)
I was assuming that both servers were part of the same setup, i.e. webserver and db server.
In such a setup the machines usually need to trust each other anyways to a degree that
it becomes nearly impossible to "insulate" them from each other.
In that latter scenario an addtl serial link doesn't take away any security.
Ofcourse one should *never* wire up two servers of distinct customers that way!
Seriousy, for two servers I wouldn't consider this a hack but good practice.
It's a hack when you have more than two servers and are still
too penurious to buy a friggin terminal server.
yes,
yes,
yes,
and "umm, who cares".
any more questions?
Hey, no wonder you are posting as AC, given you have obviously never worked on a worthwhile dataset.
It is common practice to do bulk imports on a non-indexed table and create the index afterwards.
It's done that way for the simple reason that bulk indexing is *much* faster than having the db
do its index lookup/update magic for each insert.
Sure, there's no difference when you're dealing a few thousand rows.
Nonetheless your statement shows that you've never tried it on a few million rows...
Hmm, where can I buy that $400 jukebox that will also write my DVDs?
Because with a single writer (or even a bunch of them) writing 200 discs is quite a painful process.
You're looking at 13hrs writing time and you can't go away because you have to babysit (swap disc, write label)
every two minutes.
Unless you need fast random access to your archive then tape is still the way to go.
A single AIT4-drive sets you back about $1500. Each tape holds 200G so you get
4 tapes instead of 200 discs. Quite a difference..
You said:
Well, what does it matter, imho this whole agile, XP stuff is made up by crackmonkeys anyways.
If you want to software that works then you need three things:
- One Architect (or a team that acts like one)
- A bunch of highly skilled codemonkeys
- A plan which is turned into a spec by the architect and which only changes around *pre-defined* joints
Most projects that I have encountered failed on all three of these points and tried to make up
by going after "agile practices", standup meetings, pair programming and all that rubbish.
And most of them didn't even notice that not even the best process (if its worth a damn) can make
up for the lack of any of the above. Not a bit.
If you don't have an architect then you don't even have to start. Your software will be flawed from the getgo
and the accumulating design failures will make your work slower and more expensive every day.
If you don't have good codemonkeys but rather buy three "fresh'outta'college" students for the price of one
qualified hacker (cuz 3 for the price of one is a great deal, right??) then you're doomed for the architect
either leaving early pissed or, worse, him sanctioning that kind of staffing due to a vested interest in
a longer chain-of-blame (which tells you all about how good of a choice he was).
If you don't have a plan and stick to it then you're lost in either case.
Software as flexible as a car that can be turned into a plane overnight is a pipe dream.
You either know what you want to do or you don't. In the latter case you shouldn't even start either.
None of that can be fixed with any kind of process. Otoh, a qualified team already
has or will quickly develop whatever process works best for them.
All this XP nonsense is made and picked up by the clueless PMs and PHBs crowd that's
always in desperate need to justify their failure. Which is good. For the people who
actually get work done. You spend your time on tweak, tune and blame the process.
Meanwhile those with a clue just sit down and build youtube.
Thanks, please keep writing these books!