Laugh now, but if everything you buy has an RFID in it, why wouldn't you want a Google House type search?
Load Google House into your house's HAL9000, plug your floor plan into it, put sensors in appropriate spots, and bingo!
Where are my keys? Ah, I see they are on the wall hook, not on the table. Where's the remote? X marks the spot. Did junior take my playboy and hide it under his bed *again*? Atta boy - guess I'll just buy another copy.:)
Free market?? Maybe.
But guess who owns the one and only undersea fiber link to Mauritius? France Telecom.
Wireless may be available, but that link to the outside world is still expensive. We have a call center there, and we definitely pay for the monopoly in our circuit charges.
It's crap because who wants a 40GB hard drive anyway? The last drive I bought, 3 years ago, was 60GB because that was the magic price point back then.
It's crap because 1GB of "Apple" memory is still outrageously overpriced.
"Perhaps Apple actually listened to people complaining about overpriced upgrades." What?! So they've come all the way down from *shit my pants* bad to just *I can't believe anyone would pay that much*
You're right about the culture, but the gov't over there also spends huge on infrastructure projects like this one. We're not too far away - check out gcmtravel.com, for example.
The dumb part of this whole thing in Japan is that almost everyone uses public transportation, and they have awesome train and bus systems. Driving in Tokyo or Yokohama is slightly less fun than bamboo under the fingernails.
P.S. You still are judged by your shoes in Tokyo. It's one of the first thing people look at, especially the teenies.
I wrote a simple shell script that rips, encodes, titles and tags, and stores in a directory. I used it to convert my entire CD library, one disc at a time.
It uses dagrab or cdparanoia, your choice, for ripping, LAME for encoding. It also uses a perl module for CDDB access.
Send me a request at kris at burkhardt dot org and I'll email you the script.
In our enterprise, SPs are the norm. I've also worked on projects where embedded static sql with host vars was the standard (high volume order processing app), and where dynamic sql was the norm (quick build web site).
As with most architecture choices, SPs have their place. Here are the guidelines we try to enforce: 1. For online actions, KISS. Do data access only, unless the alternative is incredibly difficult biz logic in the app when it would be simple in the SP. 2. For batch, SPs are okay, but you must use cursors, checkpointing, control table, etc. In short, a proper batch arch. 3. Keep dynamic sql in the SP to an absolute minimum. Exceptions must be approved by God.
Despite the guidelines, main issue we face are shitty, unmaintainable SPs, where business logic is spread between app logic and SP. Second issue is unreadable SPs because they are building dynamic sql and executing it. Bad, bad, bad.
Whether or not the compile time affects you is another decision. If you can throw cash at the problem, more CPU is often a pretty good answer and cheaper than a good programmer. If you're trying to run your website on a 486, well, SPs are a better call.
Consider this: most items that require firmware updates attach in some way to a PC, and get those updates through the PC.
What if there were some kind of a standardized firmware upgrade protocol (kind of like the windows automatic updater service-thingy) that kept track of your devices, notified you when updates were available, and flashed the updates for you?
End user no longer has to be very savvy, but rather just has to have the firmware updater software installed. Updater reaches out to product web services (provided by manufacturers) for each product it is aware of, and checks for updates, and downloads 'em.
Network devices (such as wireless routers) could find their own manufacturer, and update themselves (or not, of course, depending on user prefs)
If I try to install SAP at my business, and I have problems, I can go to SAP for help, because it's included in the licensing fee. If they can't fix it, I may or may not be able to sue, depending on the contract provisions, but they will generally try to make it right to protect their reputation in the marketplace.
If that type of recourse is important to me, I may decide to go with SAP instead of an open-source alternative.
That's not to say I wouldn't get better service with open source and committed developers, just that there is no direct recourse if I don't. If I'm a big corporation, and I bitch at RSA to fix their software, they listen and give me results because I paid for their software. If I bitch at Rusty Russell about iptables(bless his code!), he'll likely first be annoyed, and may or may not prioritize my requested fix.
I assume you won't be going open source for everything, but will rather evaluate on a need-by-need basis.
As you evaluate each need, some special questions apply: - Legal: Do we want/need legal recourse if something goes wrong with this piece of software? - Do we plan to extend and enhance this product ourselves? Are we willing to share our work with the larger OSS community?
And for each OSS candidate: - Liveliness of maintainers: are they issuing regular updates? Are they meeting the needs of the community? - Conversely, does our organization have the right skills to help update the software? - Is the userbase big enough to ensure decent longevity of the product? (Safety in numbers) - Do we need and can we get tech support that meets our SLAs?
There must be a bunch of other questions to be asked, but you get the idea. Again, I suggest you treat OSS as one tool to help you on a need-by-need basis, rather than the answer to your business' cost savings dreams.
I don't buy it. "Port knocking" feels like more administrative overhead for not much gain.
a)It causes me to have to remember, code, and administrate another password, which by the way, is common to all users
b)It is trivial to sniff out anywhere between client and server
It's akin to hiding your door key under a rock - it's secure until the first time someone sees you retrieving it and opening your door with it.
You don't go all in in Texas Hold'em when your cards suck and your opponent is obligated to call your bluff.
Is Darl really bluffing, or is there something we're missing? Linus did not code the entire kernel all by himself - what if someone slipped some copied code in there and passed it off as orginal? Possible?
What if, to use Linus' map maker example against him, SCO has found a code bug that in Linux that matches a code bug they own?
As someone said in previous Slashdot comment, Darl is betting the bank. As a CEO, you only do that when it's your only option, when your case is rock solid, or when you intend to defraud the public. Which is it, Darl?
Slashdot Mirror
I live in the Philippines. Prepaid is the way most people go here. Phones are all GSM and will work on any network - just switch the SIM.
People will literally switch carriers and phone numbers just to get 300 free text messages for switching (about $6 worth of service.)
Laugh now, but if everything you buy has an RFID in it, why wouldn't you want a Google House type search?
:)
Load Google House into your house's HAL9000, plug your floor plan into it, put sensors in appropriate spots, and bingo!
Where are my keys? Ah, I see they are on the wall hook, not on the table. Where's the remote? X marks the spot. Did junior take my playboy and hide it under his bed *again*? Atta boy - guess I'll just buy another copy.
Hey editors, mod me down if you like, but this question doesn't seem to have broad appeal to the slashdot community.
I hope the student in question doesn't get screwed, but does he really need our advice?
Free market?? Maybe. But guess who owns the one and only undersea fiber link to Mauritius? France Telecom. Wireless may be available, but that link to the outside world is still expensive. We have a call center there, and we definitely pay for the monopoly in our circuit charges.
It's crap because who wants a 40GB hard drive anyway? The last drive I bought, 3 years ago, was 60GB because that was the magic price point back then.
It's crap because 1GB of "Apple" memory is still outrageously overpriced.
"Perhaps Apple actually listened to people complaining about overpriced upgrades." What?! So they've come all the way down from *shit my pants* bad to just *I can't believe anyone would pay that much*
You're right about the culture, but the gov't over there also spends huge on infrastructure projects like this one. We're not too far away - check out gcmtravel.com, for example.
The dumb part of this whole thing in Japan is that almost everyone uses public transportation, and they have awesome train and bus systems. Driving in Tokyo or Yokohama is slightly less fun than bamboo under the fingernails.
P.S. You still are judged by your shoes in Tokyo. It's one of the first thing people look at, especially the teenies.
I wrote a simple shell script that rips, encodes, titles and tags, and stores in a directory. I used it to convert my entire CD library, one disc at a time.
It uses dagrab or cdparanoia, your choice, for ripping, LAME for encoding. It also uses a perl module for CDDB access.
Send me a request at kris at burkhardt dot org and I'll email you the script.
In our enterprise, SPs are the norm. I've also worked on projects where embedded static sql with host vars was the standard (high volume order processing app), and where dynamic sql was the norm (quick build web site).
As with most architecture choices, SPs have their place. Here are the guidelines we try to enforce:
1. For online actions, KISS. Do data access only, unless the alternative is incredibly difficult biz logic in the app when it would be simple in the SP.
2. For batch, SPs are okay, but you must use cursors, checkpointing, control table, etc. In short, a proper batch arch.
3. Keep dynamic sql in the SP to an absolute minimum. Exceptions must be approved by God.
Despite the guidelines, main issue we face are shitty, unmaintainable SPs, where business logic is spread between app logic and SP. Second issue is unreadable SPs because they are building dynamic sql and executing it. Bad, bad, bad.
Whether or not the compile time affects you is another decision. If you can throw cash at the problem, more CPU is often a pretty good answer and cheaper than a good programmer. If you're trying to run your website on a 486, well, SPs are a better call.
Consider this: most items that require firmware updates attach in some way to a PC, and get those updates through the PC.
What if there were some kind of a standardized firmware upgrade protocol (kind of like the windows automatic updater service-thingy) that kept track of your devices, notified you when updates were available, and flashed the updates for you?
End user no longer has to be very savvy, but rather just has to have the firmware updater software installed. Updater reaches out to product web services (provided by manufacturers) for each product it is aware of, and checks for updates, and downloads 'em.
Network devices (such as wireless routers) could find their own manufacturer, and update themselves (or not, of course, depending on user prefs)
If I try to install SAP at my business, and I have problems, I can go to SAP for help, because it's included in the licensing fee. If they can't fix it, I may or may not be able to sue, depending on the contract provisions, but they will generally try to make it right to protect their reputation in the marketplace.
If that type of recourse is important to me, I may decide to go with SAP instead of an open-source alternative.
That's not to say I wouldn't get better service with open source and committed developers, just that there is no direct recourse if I don't. If I'm a big corporation, and I bitch at RSA to fix their software, they listen and give me results because I paid for their software. If I bitch at Rusty Russell about iptables(bless his code!), he'll likely first be annoyed, and may or may not prioritize my requested fix.
I assume you won't be going open source for everything, but will rather evaluate on a need-by-need basis.
As you evaluate each need, some special questions apply:
- Legal: Do we want/need legal recourse if something goes wrong with this piece of software?
- Do we plan to extend and enhance this product ourselves? Are we willing to share our work with the larger OSS community?
And for each OSS candidate:
- Liveliness of maintainers: are they issuing regular updates? Are they meeting the needs of the community?
- Conversely, does our organization have the right skills to help update the software?
- Is the userbase big enough to ensure decent longevity of the product? (Safety in numbers)
- Do we need and can we get tech support that meets our SLAs?
There must be a bunch of other questions to be asked, but you get the idea. Again, I suggest you treat OSS as one tool to help you on a need-by-need basis, rather than the answer to your business' cost savings dreams.
I don't buy it. "Port knocking" feels like more administrative overhead for not much gain.
a)It causes me to have to remember, code, and administrate another password, which by the way, is common to all users
b)It is trivial to sniff out anywhere between client and server
It's akin to hiding your door key under a rock - it's secure until the first time someone sees you retrieving it and opening your door with it.
You don't go all in in Texas Hold'em when your cards suck and your opponent is obligated to call your bluff.
Is Darl really bluffing, or is there something we're missing? Linus did not code the entire kernel all by himself - what if someone slipped some copied code in there and passed it off as orginal? Possible?
What if, to use Linus' map maker example against him, SCO has found a code bug that in Linux that matches a code bug they own?
As someone said in previous Slashdot comment, Darl is betting the bank. As a CEO, you only do that when it's your only option, when your case is rock solid, or when you intend to defraud the public. Which is it, Darl?