In other words, you're characterizing simple inertia (sticking with what you already know) as superior predictability. While it's certainly true that what you know is more predictable than what you don't, it's hardly an inherent disadvantage of F/LOSS; spend a few months using or testing the F/LOSS solution (just as you did the MS solution), and then it too will be predictable!
Actually, my point was that the sheer volume of testing that occurs around some closed-source products - MSFT, ORCL, etc - does tend to come up with some very predictible recipies. Not that we aren't getting to the point on some OSS that we can say the same thing, but the original post was more along the lines of "Why wouldn't you move to something new?"
For example, there've been several times when I've been using something like MySQL where I run into an issue and find out through digging that a few other people have seen it to, even that there's a bug report out for it. With DB2/Oracle/IFX, I can pull down tons of "Best Practices" documentation where people have said, "If you do this, it works thusly." Not saying that it works better, but that there are well-trodden paths that are very well tested. In the enterprise, there's not much OSS that's had the same level of thoroughness added to it.
There are some - the kernel, apache, perl, etc - that are very well known and predictible. Others are less so. This is in part because this kind of predictibility hasn't been a real concern for many projects. Fixing a serious (but well known) bug and causing a random-seeming glitch elsewhere is considered to be a Good Thing for home-user type software, but a bad one for enterprise software. Its a completely different mindset.
I do agree with many of your points by the way - and I use and enjoy OSS where its appropriate. But its far from a silver bullet.
As a comparison, while I like 10.3, I'm still not quite sure why I had to pay a full-OS price for it, compared to 10.2. Just like every other Apple fan, I'll probably empty my wallet for the newest OS, but it's disappointing me more and more each time when it turns out I'm paying for minor tweaks and add-ons.
Sigh. You didn't. Happy now? You paid the upgrade price. The real price is US$499, but the upgrade is $129 to anyone with another MacOS license. And they'll take your word for it. And, since MacOS licenses can transfer with hardware, there's a license sold for every single Mac in existance (and then some). So when you bought your Mac, you got a license - which entitled you to the upgrade price.
As for the timespan - what, you want less frequent innovation? Er, sure - this won't be on sale for another 10 months or so yet. Happier?
I believe that you mean that you'd like your mail program to run a spelling check... or possibly to run a spellcheck. But unless you mean a program called spellcheck you need the indefinate article. And the "to" as well. At least, if you want to receive your own email...
I had used MySQL for a project at our facility for a couple of years and it had worked great. Due to the success of the project, corp headquarters decided to try to implement the project at other facilities, but they balked at MySQL and forced me to convert the project to MS SQL
Of course, now look at it from their side, and compare the cost and availability of people who know MS SQL, its strengths and its weaknesses, with those who know MySQL. Both inside and outside of the company. It does seem like they made a poor choice by having you do the conversion if you're not an MS SQL expert (I've had properly configured Sql Server sites running just fine with vast amounts of access, you just need to know what you're doing, just like everything else). But the alternative could have been to have all of the MS guys in the same boat as you, but with improperly running MySQL instances instead. Not saying that they did everything right, or even that it was the right thing to do, but that's where they're coming from.
Ah, the problem I have seen is that it doesn't work. It drags my job out for hours longer that it needs to be, makes it really boring and I spend more time dealing with crap than actual work.
Right, but if the company has a choice between pissing you off and having a solution that, while not perfect, will run an aspect of their business that would cost them hundreds of $k per hour if it went down, or keep a smaller staff of very happy techies and occasionally run into an issue that they hadn't foreseen, guess which one they'll pick? Even if the second option just has a greater risk of running into an unforseen issue. Its not about you, really. Or about Microsoft for that matter. Its about the business, and making a fiscally responsible choice, which invariably means reducing unknowns.
Large Corperations with loads of money just seem to go fo M$ software. Doesn't matter how good it is or if it gets the job done they just use it. That is the problem I run into.
The thing is that, for the most part, it does work. Its also extremely well tested and what weaknesses there are are well known and documented. This is one area where the OSS camp has yet to catch up - and I don't mean providing access to a Bugzilla database with 100,000+ known issues, mostly minor. In the business world, predictibility wins out over other areas nine times out of ten.
Heck, even if I know that everything works perfectly but that my server will only stay up for 10 days in a row before performance degrades, if I have a 15 minute reboot window every week then that's fine too. I'd much rather go with a known solution - with workarounds as needed - than an unproven one that may be better. In that situation, a machine that stayed up for the most part but would randomly stop servicing requests once a quarter - while far superior in uptime stats - would be a greatly inferior solution. Its a different mindset.
Of course, this comment is slanted towards enterprise customers.
Re:Desktop Manager is Amazing
on
Hacking Quartz
·
· Score: 4, Insightful
I really have to say that Desktop Manager is amazing. It even has eye candy transforms between desktops (such as the sides of a cube representation of things).
Good... but not exactly amazing... from TFA:
Q:[Y]our app feels faster than any of the competing apps out there by an order of magnitude, even though you arguably throw a hell of a lot more eye candy in there and you've recently made it even faster. Where is this speed coming from?
A:Apple:). The actual 'switching' is performed by calling the secret API functions above. This is actually implemented in the Window Manager and hence is as fast as if I could delve in there myself and manipulate them 'by hand'. The transitions eye-candy in later releases is actually using Apple's own code.
Does that mean that it's good code? Absolutely. But not startlingly good code, since most of the heavy lifting was done by the OS itself (Apple uses similar transitions for switching between multiple users, for example - which would lead me to belive that had Apple done this they would have used something visually distinctive for the desktop switch, come to think of it).
Americans really need to kick their car manufacturers and petrol resellers in gear. I understand that some of the sillies are caused by the petrol being 87 and 92 octane, but still, my wife's car which is a 10 years old Renault delivers 42+ MPG while kicking 0-60 in under 11s and mine which is a fairly new Daihatsu delivers 55+ with 0-60 around 8.5s. So the numbers which are quoted around this thread (22-32) seem outright silly to me and any other European for that matter.
As much as I tend to agree with your general sentiment, you are aware that the US gallon is significantly smaller than the Imperial gallon, right?
Also, over here a 10-11 second 0-60 is considered to be about the slowest "acceptable" acceleration by most drivers. Not all, admittedly, but a large majority.
I mean this literally. ie someone who's not on the list may find their first email filtered, but once they try enough times (assuming they're not a spammer), they'll get through
Bzzzt! But thank you for playing. You're now using a circular definition - saying that someone can avoid being detected as a spammer if and only if the system can detect that they're not a spammer. Whoops! I'm not trying to get nasty here, just picky... this is indeed the underlying problem of almost all of these solutions. As long as there's a way in, then its not truly solid (and spam will avoid to use the way in if the security becomes commonplace) - and without a way in, its not overly useful. Which is exactly why adoption of these proposals is slim to none today.
I wasn't aware that they had to come out of a pre-allocated pool, formed when the company is incorporated (I'm slightly familiar with that paperwork).
That's because they don't. When a company incorporates, in most states they are required to set a cap on the maximum number of shares that they can issue. Increasing this cap is relatively trivial. Issuing new stock is only slightly less trivial. Having formed several corporations, and currently being an executive and substantial shareholder of one, I'm more than slightly familiar with the paperwork myself. The parent poster is well-meaning, but ill-informed.
But from the article "Today, thousands of people fly model rockets that range in size from about 12 inches to more than 30 feet tall." Now. That covers quite a range there
Exactly. You could have thousands of people flying 12 inch rockets, and one flying a 31 foot rocket, and that sentence would still be just as true. I'd like to see some more breakdown of that personally, purely because its such a vague yet emotionally charged claim.
Actually, for the tasks it was designed to solve, it remains remarkably good. Of course, its frequently used in ways that it shouldn't be, by people who don't know what they're doing. Kinda like FORTRAN in a sense. At one point it was the 9th most popular (in LOC, not in favoritism) language - not that long ago even.
Note: that sounds more impressive than it is because after position 5-6 the number of LOC have really dropped off.
But hey, it was fun. If you know any good offsite 4GL coding gigs, pass 'em along;-) Sometimes nostalgia is a good thing. Besides, then I wouldn't have wasted the time it took to take those "[C|D]4GL Certified Professional" tests...
That's trivial. All purchased lists have numbers seeded into them, this should be the same way. Once you have FTC numbers that are only published in the list, you can easily monitor inbound connections and compare them against a list of telemarketer trunks to find out who to fine.
This wouldn't be perfect, because some people (those recorded announcements) do use serial dialing, but that's really pretty rare these days.
Shame? Hey, here's a newsflash - I was a developer. I was given a set of fairly challenging requirements (respose time, interfacing to a Rockwall predictive dialer, agent ease of use, updatability, etc) and some interesting hardware (Data General boxen running Informix Online v6 of all things).
You know what? I did my job. Which I was happy to have, and to be able to do. Which wasn't even the point of my post, which was pointing out that even back them ('92) you could get your number scrubbed from the lists of the ethical telemarketers). You want to crusade against people using the phone, be my guest. But no, I feel no shame for writing solid code for a legitimate business. Some of it was still being used years later, which I happen ti think was pretty cool. I guess that makes me that much worse, huh.
I used to work for a telemarketing company doing calls for AT&T's universal card. That's right, if you got bugged during dinner by someone selling you one of their credit cards, I wrote the Informix-4GL app that guided the agent through the sale. Ah, those were the days.
Anyway, at that time at least, AT&T was very dilligent in requiring that we scrubbed the numbers they gave us against the do not call lists. They were also very focussed on staying within legal calling hours, etc.
Then again, AT&T has many, many divisions who may or may not talk to each other and could have very different standards. Also, depending on who they outsourced their outbound calling to, they may have gone with a low-cost less competent provider. Both of those would surprise me though - this was one area where they at least used to pride themselves in their quality. Or at least in our quality.
It used to mean something over here too, but it got sufficiently diluted (Sanitation Engineer?). Now the only thing that matters is if you are a "Professional Engineer" which is far from a trivial accomplishment.
Especially when the developer is green in whatever industry they're developing to, the users can kill the usability of an app by nitpicking it to death--there is no real overall vision.
So... if the developer tries to do something in a field that he has no exposure to, and the users complain that he's missed the point, its somehow their fault? Hmm... whatever.
Oh, but that's all right! None of the prevalent vendors permit CDs that have been opened to be returned. You could've duplicated it, after all, or extracted the tracks.
So return it saying that it doesn't play, and get a replacement. Don't open the replacement. Return the replacement. Pretty simple...
9%? Taking that as true (I honestly have no idea), then that's a great time to do this.
Why? Because all of us (yes, I'm included) who have HDTV sets right now would jump on this in a heartbeat. Once a standard emerges, or equipment supports all competing standards, sales of high definition DVD systems (recorders or not) will skyrocket - at least to the 9% of the population who own the sets. Watching regular DVDs (even on fancy schmancy $1k DVD players) once you've been exposed to HDTV gets pretty old.
Really, email clients ought to make this easier, with a nice big "Add to white list" button next to every email address. This way the filter doesn't accidentally filter legit email, but you should still receive at least one email from someone even if they're not on the list.
Considereing that every single spam message can be sent out with a uniquely generated "From:" address, how would this help? Once you've guaranteed a method that would result in a single email getting through, and that method becomes well known, all SPAM will take advantage of it. At least all of the smart SPAM will.
So you want iTunes to take files that it isn't aware of, copy them to a different directory and then become aware of the files? Doesn't that sound slightly contrdictory to you? Or do you mean you want it to copy files to the library folder as you add them? IN which case I suggest you check the options again.
No, he's talking about having the files in a directory somewhere and setting it up so that if he (or anyone else, think server here) copies a file into that heirarchy, iTunes automatically notices it and adds it to the database.
It should it be easy enough to script the refresh, but its still more of a pain that it should be.
The reason for this, conversely, is that Apple is really trying to minimize the times that people think of "Files" instead of "Music" or "Photos". But its one of those things that works well in the normal case, but falls down when people try to do interesting things outside the box with it.
Shouldn't those be escaped to < and for any XML conversion anyway? I'm not just being glib, I've written my own XML-RPC implementations... so if the description does include an unescaped , wouldn't that be Wrong?
Obviously allowing for safety limitations--after all, you can't have a big waffle iron on your desk
I beg to differ. For an extended period of time when I was trying to find time to fix it, I did indeed have a big waffle iron on my desk. Even made the occasional waffle with it.
Slashdot Mirror
In other words, you're characterizing simple inertia (sticking with what you already know) as superior predictability. While it's certainly true that what you know is more predictable than what you don't, it's hardly an inherent disadvantage of F/LOSS; spend a few months using or testing the F/LOSS solution (just as you did the MS solution), and then it too will be predictable!
Actually, my point was that the sheer volume of testing that occurs around some closed-source products - MSFT, ORCL, etc - does tend to come up with some very predictible recipies. Not that we aren't getting to the point on some OSS that we can say the same thing, but the original post was more along the lines of "Why wouldn't you move to something new?"
For example, there've been several times when I've been using something like MySQL where I run into an issue and find out through digging that a few other people have seen it to, even that there's a bug report out for it. With DB2/Oracle/IFX, I can pull down tons of "Best Practices" documentation where people have said, "If you do this, it works thusly." Not saying that it works better, but that there are well-trodden paths that are very well tested. In the enterprise, there's not much OSS that's had the same level of thoroughness added to it.
There are some - the kernel, apache, perl, etc - that are very well known and predictible. Others are less so. This is in part because this kind of predictibility hasn't been a real concern for many projects. Fixing a serious (but well known) bug and causing a random-seeming glitch elsewhere is considered to be a Good Thing for home-user type software, but a bad one for enterprise software. Its a completely different mindset.
I do agree with many of your points by the way - and I use and enjoy OSS where its appropriate. But its far from a silver bullet.
As a comparison, while I like 10.3, I'm still not quite sure why I had to pay a full-OS price for it, compared to 10.2. Just like every other Apple fan, I'll probably empty my wallet for the newest OS, but it's disappointing me more and more each time when it turns out I'm paying for minor tweaks and add-ons.
Sigh. You didn't. Happy now? You paid the upgrade price. The real price is US$499, but the upgrade is $129 to anyone with another MacOS license. And they'll take your word for it. And, since MacOS licenses can transfer with hardware, there's a license sold for every single Mac in existance (and then some). So when you bought your Mac, you got a license - which entitled you to the upgrade price.
As for the timespan - what, you want less frequent innovation? Er, sure - this won't be on sale for another 10 months or so yet. Happier?
I'd like my mail program run spell check
I believe that you mean that you'd like your mail program to run a spelling check... or possibly to run a spellcheck. But unless you mean a program called spellcheck you need the indefinate article. And the "to" as well. At least, if you want to receive your own email...
I had used MySQL for a project at our facility for a couple of years and it had worked great. Due to the success of the project, corp headquarters decided to try to implement the project at other facilities, but they balked at MySQL and forced me to convert the project to MS SQL
Of course, now look at it from their side, and compare the cost and availability of people who know MS SQL, its strengths and its weaknesses, with those who know MySQL. Both inside and outside of the company. It does seem like they made a poor choice by having you do the conversion if you're not an MS SQL expert (I've had properly configured Sql Server sites running just fine with vast amounts of access, you just need to know what you're doing, just like everything else). But the alternative could have been to have all of the MS guys in the same boat as you, but with improperly running MySQL instances instead. Not saying that they did everything right, or even that it was the right thing to do, but that's where they're coming from.
Ah, the problem I have seen is that it doesn't work. It drags my job out for hours longer that it needs to be, makes it really boring and I spend more time dealing with crap than actual work.
Right, but if the company has a choice between pissing you off and having a solution that, while not perfect, will run an aspect of their business that would cost them hundreds of $k per hour if it went down, or keep a smaller staff of very happy techies and occasionally run into an issue that they hadn't foreseen, guess which one they'll pick? Even if the second option just has a greater risk of running into an unforseen issue. Its not about you, really. Or about Microsoft for that matter. Its about the business, and making a fiscally responsible choice, which invariably means reducing unknowns.
Large Corperations with loads of money just seem to go fo M$ software. Doesn't matter how good it is or if it gets the job done they just use it. That is the problem I run into.
The thing is that, for the most part, it does work. Its also extremely well tested and what weaknesses there are are well known and documented. This is one area where the OSS camp has yet to catch up - and I don't mean providing access to a Bugzilla database with 100,000+ known issues, mostly minor. In the business world, predictibility wins out over other areas nine times out of ten.
Heck, even if I know that everything works perfectly but that my server will only stay up for 10 days in a row before performance degrades, if I have a 15 minute reboot window every week then that's fine too. I'd much rather go with a known solution - with workarounds as needed - than an unproven one that may be better. In that situation, a machine that stayed up for the most part but would randomly stop servicing requests once a quarter - while far superior in uptime stats - would be a greatly inferior solution. Its a different mindset.
Of course, this comment is slanted towards enterprise customers.
Good
Does that mean that it's good code? Absolutely. But not startlingly good code, since most of the heavy lifting was done by the OS itself (Apple uses similar transitions for switching between multiple users, for example - which would lead me to belive that had Apple done this they would have used something visually distinctive for the desktop switch, come to think of it).
Americans really need to kick their car manufacturers and petrol resellers in gear. I understand that some of the sillies are caused by the petrol being 87 and 92 octane, but still, my wife's car which is a 10 years old Renault delivers 42+ MPG while kicking 0-60 in under 11s and mine which is a fairly new Daihatsu delivers 55+ with 0-60 around 8.5s. So the numbers which are quoted around this thread (22-32) seem outright silly to me and any other European for that matter.
As much as I tend to agree with your general sentiment, you are aware that the US gallon is significantly smaller than the Imperial gallon, right?
Also, over here a 10-11 second 0-60 is considered to be about the slowest "acceptable" acceleration by most drivers. Not all, admittedly, but a large majority.
I mean this literally. ie someone who's not on the list may find their first email filtered, but once they try enough times (assuming they're not a spammer), they'll get through
Bzzzt! But thank you for playing. You're now using a circular definition - saying that someone can avoid being detected as a spammer if and only if the system can detect that they're not a spammer. Whoops! I'm not trying to get nasty here, just picky... this is indeed the underlying problem of almost all of these solutions. As long as there's a way in, then its not truly solid (and spam will avoid to use the way in if the security becomes commonplace) - and without a way in, its not overly useful. Which is exactly why adoption of these proposals is slim to none today.
I wasn't aware that they had to come out of a pre-allocated pool, formed when the company is incorporated (I'm slightly familiar with that paperwork).
That's because they don't. When a company incorporates, in most states they are required to set a cap on the maximum number of shares that they can issue. Increasing this cap is relatively trivial. Issuing new stock is only slightly less trivial. Having formed several corporations, and currently being an executive and substantial shareholder of one, I'm more than slightly familiar with the paperwork myself. The parent poster is well-meaning, but ill-informed.
But from the article "Today, thousands of people fly model rockets that range in size from about 12 inches to more than 30 feet tall." Now. That covers quite a range there
Exactly. You could have thousands of people flying 12 inch rockets, and one flying a 31 foot rocket, and that sentence would still be just as true. I'd like to see some more breakdown of that personally, purely because its such a vague yet emotionally charged claim.
Actually, for the tasks it was designed to solve, it remains remarkably good. Of course, its frequently used in ways that it shouldn't be, by people who don't know what they're doing. Kinda like FORTRAN in a sense. At one point it was the 9th most popular (in LOC, not in favoritism) language - not that long ago even.
;-) Sometimes nostalgia is a good thing. Besides, then I wouldn't have wasted the time it took to take those "[C|D]4GL Certified Professional" tests...
Note: that sounds more impressive than it is because after position 5-6 the number of LOC have really dropped off.
But hey, it was fun. If you know any good offsite 4GL coding gigs, pass 'em along
That's trivial. All purchased lists have numbers seeded into them, this should be the same way. Once you have FTC numbers that are only published in the list, you can easily monitor inbound connections and compare them against a list of telemarketer trunks to find out who to fine.
This wouldn't be perfect, because some people (those recorded announcements) do use serial dialing, but that's really pretty rare these days.
Shame? Hey, here's a newsflash - I was a developer. I was given a set of fairly challenging requirements (respose time, interfacing to a Rockwall predictive dialer, agent ease of use, updatability, etc) and some interesting hardware (Data General boxen running Informix Online v6 of all things).
You know what? I did my job. Which I was happy to have, and to be able to do. Which wasn't even the point of my post, which was pointing out that even back them ('92) you could get your number scrubbed from the lists of the ethical telemarketers). You want to crusade against people using the phone, be my guest. But no, I feel no shame for writing solid code for a legitimate business. Some of it was still being used years later, which I happen ti think was pretty cool. I guess that makes me that much worse, huh.
I used to work for a telemarketing company doing calls for AT&T's universal card. That's right, if you got bugged during dinner by someone selling you one of their credit cards, I wrote the Informix-4GL app that guided the agent through the sale. Ah, those were the days.
Anyway, at that time at least, AT&T was very dilligent in requiring that we scrubbed the numbers they gave us against the do not call lists. They were also very focussed on staying within legal calling hours, etc.
Then again, AT&T has many, many divisions who may or may not talk to each other and could have very different standards. Also, depending on who they outsourced their outbound calling to, they may have gone with a low-cost less competent provider. Both of those would surprise me though - this was one area where they at least used to pride themselves in their quality. Or at least in our quality.
It used to mean something over here too, but it got sufficiently diluted (Sanitation Engineer?). Now the only thing that matters is if you are a "Professional Engineer" which is far from a trivial accomplishment.
Especially when the developer is green in whatever industry they're developing to, the users can kill the usability of an app by nitpicking it to death--there is no real overall vision.
So... if the developer tries to do something in a field that he has no exposure to, and the users complain that he's missed the point, its somehow their fault? Hmm... whatever.
Oh, but that's all right! None of the prevalent vendors permit CDs that have been opened to be returned. You could've duplicated it, after all, or extracted the tracks.
So return it saying that it doesn't play, and get a replacement. Don't open the replacement. Return the replacement. Pretty simple...
9%? Taking that as true (I honestly have no idea), then that's a great time to do this.
Why? Because all of us (yes, I'm included) who have HDTV sets right now would jump on this in a heartbeat. Once a standard emerges, or equipment supports all competing standards, sales of high definition DVD systems (recorders or not) will skyrocket - at least to the 9% of the population who own the sets. Watching regular DVDs (even on fancy schmancy $1k DVD players) once you've been exposed to HDTV gets pretty old.
Really, email clients ought to make this easier, with a nice big "Add to white list" button next to every email address. This way the filter doesn't accidentally filter legit email, but you should still receive at least one email from someone even if they're not on the list.
Considereing that every single spam message can be sent out with a uniquely generated "From:" address, how would this help? Once you've guaranteed a method that would result in a single email getting through, and that method becomes well known, all SPAM will take advantage of it. At least all of the smart SPAM will.
So you want iTunes to take files that it isn't aware of, copy them to a different directory and then become aware of the files? Doesn't that sound slightly contrdictory to you? Or do you mean you want it to copy files to the library folder as you add them? IN which case I suggest you check the options again.
No, he's talking about having the files in a directory somewhere and setting it up so that if he (or anyone else, think server here) copies a file into that heirarchy, iTunes automatically notices it and adds it to the database.
It should it be easy enough to script the refresh, but its still more of a pain that it should be.
The reason for this, conversely, is that Apple is really trying to minimize the times that people think of "Files" instead of "Music" or "Photos". But its one of those things that works well in the normal case, but falls down when people try to do interesting things outside the box with it.
Gotcha. So if you wanted to send the plain text string " big small " you'd have to first HTML-encode it:
big < small
and then XML encode that:
big < small
? Messy indeed. And yet if the spec indicated that that would be the case, not a big deal. Its the "custom" that makes it crappy.
Shouldn't those be escaped to < and for any XML conversion anyway? I'm not just being glib, I've written my own XML-RPC implementations... so if the description does include an unescaped , wouldn't that be Wrong?
Obviously allowing for safety limitations--after all, you can't have a big waffle iron on your desk
I beg to differ. For an extended period of time when I was trying to find time to fix it, I did indeed have a big waffle iron on my desk. Even made the occasional waffle with it.
Possibly they rejected it because /. had already reported this several weeks ago? Besides, that one's voluntary.