Somebody drag this guy out from his time-warp under-a-rock bunker, and make him take a vacation/tour of Japan, Korea, Hong Kong, and Taiwan. Make him see where the current state of the smart/phone is at (including stuff like Felica and GPS), how people are actually using high tech products in these places of high-churn.
Maybe then he'll be able to grasp what modern technology is at, and that five years of R&D actually left him seven years behind.
Congratulations on your genius for building out a bleeding-edge obscure OS for your parents whom I doubt are bleeding edge users, and then coming here to bitch to the choir.
Nothing wrong getting the 64bit hardware, but everything wrong with the blind, myopic optimism with the OS selection.
If you wanted all the fancy graphics and looks, then you well know it's either the solid MacOS, or XP with some nice skinning.
It's called shooting yourself in your foot.
64-bit, like SSE*, SSSE, etc will come in its own time and place driven usually by only the hard-core.
Besides, you're asking Microsoft, the people whom built Vista, the mediocre Visual C/C++ (vs Intel C++ Compiler), and took 20 years to catch up with some modern OS tech to be a cutting edge leader?
Can also create symlinks to share code between different projects, and preserves all of history. Not transparent, but it's available and it works.
CVS obliterate dates back to RCS and is done with: cvs admin -o 1.1 (for specific version) , or:1.10 (for everything up to 1.10 inclusive), 1.2:1.10 (for deleting 1.2 to 1.10). You'll need a fancy script to handle branches.
man it. SVN is still too immature if it can't do this.
Efficiency of storing binaries is very inconsequential when storage is free these days. Not only that, but efficiency of delta'ing varies and wasteful in time (lookup bsdiff) so why bother? And with the obliterate option, it makes the issue moot, and SVN unusable for binary CM and deployments.
I can access everything from CVS over ssh and VPN tunnels just fine from anywhere in the world. I don't really see a need for a complicated HTTP overhead although it can be nice, but basically says there's a no-trust relationship going on.
I just wish there CVS would maybe uses BerkeleyDB or something faster for the file db in backend so tagging isn't so slow, handles file histories over 4GB better (isn't there a better way than a full copy/replace of the,v file on commits?), and some other nits. For the enterprise development I do, CVS or Perforce are the only choices that don't have issues.
Instant traceable recovery of the tool-chain especially when spread out between multiple developer over long periods of time as long as the core dependencies don't change.
Let me give you an example: developers have been building this game with tools and related artwork. Once the release A has been made, all sources and binaries are checked-in. A year later, developers come back to localize this release for international release, but meanwhile the source and tool chain had moved on.
Do you attempt to destabilize the certified release by updating all sources and tool chain to the latest, or reduce work and time by working with the snapshot of what release A was developed in and only change artwork and displayed text?
Sometimes, if the tool chain API is stable, it should be no problem to update to the latest, but not if it's custom in-house.
How often does the OS change and does it really affect the tool chain? For example, Win32's API has been stable for 6-7 years now.
I'm sorry all of you Red Hat/Fedora/Linux people are screwed in the meantime.
Atomic commits would be nice, renames easily done on the repo with recoverable side-effects, why http? otherwise cvsweb, no binary delta is GOOD because binary-patches are SLOW and unnecessary red-herring (CVS has obliterate; what does SVN have?), handled gigs of mission-critical binaries safely so far.
The increase in efficiency is already noticeable with the small liter Atkinson pseudo-Miller cycle engine the Prius(1.5L)/Civic(1.3L) hybrids use.
Combined with running the engine at optimum RPM and storing HP overflow into the battery, plus the occasional recovery from regenerative braking, it's ludicrous to argue that gas hybrids are just marketing.
Don't forget, these gas-hybrids aren't small and low-weight as those high MPG diesels are.
The OS is irrelevant when the machines being deployed to are the same OS and flavor. Windows, Linux, etc.
Eventually, the OS updates but the tool chain updates with it. Release Management is about handling the NOW and not the whatif. Especially since stable and mature OSs don't really change that much, and aren't a toolchain dependency (unlike you RedHat people).
You have some other granular, fault tolerant, and centralized release tracking model that works better and doesn't rely on different directories, tarballs, or some other hack method?
Btw, CVS does do binary difference storage. Ever done a diff between two versions of.doc files?
SVN will never beat CVS on space-efficiency in the long run.
SVN does not have granular history obliterate whereas CVS/Perforce does, so CVS might be bigger initially, but you can always delete very old versions. These old binary versions are the ones you can rebuild from source or you really don't care anymore.
My approach for you've mentioned is to get the latest 3G phone and BT it share it with my laptop and T|X. It's not total convergence, but at least the separation allows each device to be the best it's good for.
Also, when the plane nazis tell me to turn off my phone, I can still work on other stuff in peace. Or, when I'm told I can't bring my camera phone into some government building, I still can bring my other data devices along.
This is nothing different from the way DHT bittorrent matching sections of the files, and ignoring the bad hash chunks
It's not even a new idea. You can generate super-efficient patches of files if you had local knowledge of which sections of the file are meta-data such as headers, relocation tables, etc and which is actual data. You could expand this further to generate par2-like differential patch data, and then just bittorrent all the chunks down with differential regeneration on the client-end. Sounds a lot like DHT again.
Okay, we're arguing over a faulty generalization that is not in any form a fact nor truth, but instead bullshit, and FUD.
"many cars can easily beat a Prius hybrid on fuel economy" is as true as "all geeks wear glasses" or "your momma is fat..." without any scientific numbers to fairly digest against.
Thank you for at least naming one vehicle such as the VW Golf to compare with, but it's only slightly comparable to the Prius in FE, size, and weight.
Briefly, fueleconomy.gov has the Golf at 34MPG for a diesel TDI (or 29.58MPG gasoline) with 638593.389 cubic inches on 3091 lbs over 98.9 inch wheelbase, or 0.01099/0.00956 MPG/lb respectively. 30miles * 30 days @ 34MPG @ $2.96 diesel = $78.
A Prius is 46MPG (16.42MPG more) on gasoline with 690373.25 (51779.861 more cubic inches) on 2890 lbs over a 106.3 inch wheelbase, or 0.01591 MPG/lb. 30 miles * 30 days @ 46MPG @ $3.228 gasoline = $63.
Price between the two is ~$1K MSRP. My scientific conclusion is the Prius is bigger, lighter, and more fuel efficient per pound than the diesel Golf, so a better value. Probably not as fun to drive, however.
Got another "easily beat a Prius hybrid on fuel economy"?
You know, hydrogen has practically the lowest energy density by volume than biofuels, diesel, and gasoline, making it practically insane to try to use in something portable such as vehicles. Storing, and using it makes volume matter.
Hydrogen is a waste of time, energy and resources.
Slashdot Mirror
Somebody drag this guy out from his time-warp under-a-rock bunker, and make him take a vacation/tour of Japan, Korea, Hong Kong, and Taiwan. Make him see where the current state of the smart/phone is at (including stuff like Felica and GPS), how people are actually using high tech products in these places of high-churn.
Maybe then he'll be able to grasp what modern technology is at, and that five years of R&D actually left him seven years behind.
Congratulations on your genius for building out a bleeding-edge obscure OS for your parents whom I doubt are bleeding edge users, and then coming here to bitch to the choir.
Nothing wrong getting the 64bit hardware, but everything wrong with the blind, myopic optimism with the OS selection.
If you wanted all the fancy graphics and looks, then you well know it's either the solid MacOS, or XP with some nice skinning.
It's called shooting yourself in your foot.
64-bit, like SSE*, SSSE, etc will come in its own time and place driven usually by only the hard-core.
Besides, you're asking Microsoft, the people whom built Vista, the mediocre Visual C/C++ (vs Intel C++ Compiler), and took 20 years to catch up with some modern OS tech to be a cutting edge leader?
CVS rename: /cvs
:1.10 (for everything up to 1.10 inclusive), 1.2:1.10 (for deleting 1.2 to 1.10). You'll need a fancy script to handle branches.
,v file on commits?), and some other nits. For the enterprise development I do, CVS or Perforce are the only choices that don't have issues.
ssh repository
cd
mv foo,v bar,v
(done)
Can also create symlinks to share code between different projects, and preserves all of history. Not transparent, but it's available and it works.
CVS obliterate dates back to RCS and is done with:
cvs admin -o 1.1 (for specific version) , or
man it. SVN is still too immature if it can't do this.
Efficiency of storing binaries is very inconsequential when storage is free these days. Not only that, but efficiency of delta'ing varies and wasteful in time (lookup bsdiff) so why bother? And with the obliterate option, it makes the issue moot, and SVN unusable for binary CM and deployments.
I can access everything from CVS over ssh and VPN tunnels just fine from anywhere in the world. I don't really see a need for a complicated HTTP overhead although it can be nice, but basically says there's a no-trust relationship going on.
I just wish there CVS would maybe uses BerkeleyDB or something faster for the file db in backend so tagging isn't so slow, handles file histories over 4GB better (isn't there a better way than a full copy/replace of the
Why have file-system journals?
Instant traceable recovery of the tool-chain especially when spread out between multiple developer over long periods of time as long as the core dependencies don't change.
Let me give you an example: developers have been building this game with tools and related artwork. Once the release A has been made, all sources and binaries are checked-in. A year later, developers come back to localize this release for international release, but meanwhile the source and tool chain had moved on.
Do you attempt to destabilize the certified release by updating all sources and tool chain to the latest, or reduce work and time by working with the snapshot of what release A was developed in and only change artwork and displayed text?
Sometimes, if the tool chain API is stable, it should be no problem to update to the latest, but not if it's custom in-house.
How often does the OS change and does it really affect the tool chain? For example, Win32's API has been stable for 6-7 years now.
I'm sorry all of you Red Hat/Fedora/Linux people are screwed in the meantime.
Atomic commits would be nice, renames easily done on the repo with recoverable side-effects, why http? otherwise cvsweb, no binary delta is GOOD because binary-patches are SLOW and unnecessary red-herring (CVS has obliterate; what does SVN have?), handled gigs of mission-critical binaries safely so far.
The increase in efficiency is already noticeable with the small liter Atkinson pseudo-Miller cycle engine the Prius(1.5L)/Civic(1.3L) hybrids use.
Combined with running the engine at optimum RPM and storing HP overflow into the battery, plus the occasional recovery from regenerative braking, it's ludicrous to argue that gas hybrids are just marketing.
Don't forget, these gas-hybrids aren't small and low-weight as those high MPG diesels are.
You can sample this instantly if the vehicle has MPG feedback displays (which takes in account
This is why trucks generally drive at 55mph.
That's what makes CVS great. The total transparency that allows hack a few lines of Entries and you're done in record time.
No mucking with database files, no mucking with rollback points, so on.
The OS is irrelevant when the machines being deployed to are the same OS and flavor. Windows, Linux, etc.
Eventually, the OS updates but the tool chain updates with it. Release Management is about handling the NOW and not the whatif. Especially since stable and mature OSs don't really change that much, and aren't a toolchain dependency (unlike you RedHat people).
You have some other granular, fault tolerant, and centralized release tracking model that works better and doesn't rely on different directories, tarballs, or some other hack method?
Btw, CVS does do binary difference storage. Ever done a diff between two versions of .doc files?
SVN will never beat CVS on space-efficiency in the long run.
SVN does not have granular history obliterate whereas CVS/Perforce does, so CVS might be bigger initially, but you can always delete very old versions. These old binary versions are the ones you can rebuild from source or you really don't care anymore.
It exists forever in SVN.
Oh let's not start on Broadcom and their crappy wireless chips. It's a damn crime they're pushing it on the new laptops as the "cheaper" option.
My approach for you've mentioned is to get the latest 3G phone and BT it share it with my laptop and T|X. It's not total convergence, but at least the separation allows each device to be the best it's good for.
Also, when the plane nazis tell me to turn off my phone, I can still work on other stuff in peace. Or, when I'm told I can't bring my camera phone into some government building, I still can bring my other data devices along.
This is nothing different from the way DHT bittorrent matching sections of the files, and ignoring the bad hash chunks
It's not even a new idea. You can generate super-efficient patches of files if you had local knowledge of which sections of the file are meta-data such as headers, relocation tables, etc and which is actual data. You could expand this further to generate par2-like differential patch data, and then just bittorrent all the chunks down with differential regeneration on the client-end. Sounds a lot like DHT again.
Okay, we're arguing over a faulty generalization that is not in any form a fact nor truth, but instead bullshit, and FUD.
"many cars can easily beat a Prius hybrid on fuel economy" is as true as "all geeks wear glasses" or "your momma is fat..." without any scientific numbers to fairly digest against.
Thank you for at least naming one vehicle such as the VW Golf to compare with, but it's only slightly comparable to the Prius in FE, size, and weight.
Briefly, fueleconomy.gov has the Golf at 34MPG for a diesel TDI (or 29.58MPG gasoline) with 638593.389 cubic inches on 3091 lbs over 98.9 inch wheelbase, or 0.01099/0.00956 MPG/lb respectively. 30miles * 30 days @ 34MPG @ $2.96 diesel = $78.
A Prius is 46MPG (16.42MPG more) on gasoline with 690373.25 (51779.861 more cubic inches) on 2890 lbs over a 106.3 inch wheelbase, or 0.01591 MPG/lb. 30 miles * 30 days @ 46MPG @ $3.228 gasoline = $63.
Price between the two is ~$1K MSRP. My scientific conclusion is the Prius is bigger, lighter, and more fuel efficient per pound than the diesel Golf, so a better value. Probably not as fun to drive, however.
Got another "easily beat a Prius hybrid on fuel economy"?
Sounds like Lua is more Free Software than OSS.
If you're comparing a 1000lb pound car that gets 50MPG to a 2800lb pound car that gets 50MPG, which one is better?
Yes, you do have to be in the same weight class, otherwise you're comparing apples to oranges, and the "soapbox racers" always wins.
You shouldn't try things that'll cost you more than you save. http://www.usatoday.com/news/washington/2005-07-22 -daylight-congress_x.htm
How about converting entirely to CFLs and/or raising CAFE standards? These actually try to solve something instead of hand waving.
http://www.fueleconomy.gov/feg/noframes/20680.shtm l
t ings.php?id1=2
And, it's a deathtrap: http://www.euroncap.com/content/safety_ratings/ra
I believe European crash tests are much stricter than the American's because of the possible higher European highway speeds, and more twisty roads.
You could already achieve near 100MPG in most high MPG cars with sensible driving (such as Prius and Insight), or sensible size as you've said.
Are they in the same weight class? Means nothing if you're comparing it to a soapbox racer.
Here's my bibliography:
Fuel efficiency in transportation
Get people out of their cars and big loads off big rigs, and move it over to trains.
Solves congestion and pollution. Fund it with the money what we currently export to Big Oil and terrorists.
Since MPG is a 1/x equation, a difference of 5MPG at that lower end of the scale does translate into big changes in the wallet.
It's when you get into the upper range that shifts like 60->48MPG is trivial.
When does this car come out of concept stage? Currently, that violates prize guidelines.
100MPG+ Prius STOCK:/ fall/marathon.html
i nsightcvt.html
http://www.toyota.com/html/hybridsynergyview/2005
stock Honda Insights get close to 80MPG before you start tweaking:
http://www.greenhybrid.com/compare/mileage/honda-
plugin-Prius @ 150MPG+:
http://www.evworld.com/article.cfm?storyid=818
Note, most of these date from at least 2005. Welcome back to the future.
> Many cars can easily beat a Prius hybrid on fuel economy,
Name some in the same weight class, or please mod down. The Prius is already 1500cc, and the Civic Hybrid is/was 1300cc.
You know, hydrogen has practically the lowest energy density by volume than biofuels, diesel, and gasoline, making it practically insane to try to use in something portable such as vehicles. Storing, and using it makes volume matter.
Hydrogen is a waste of time, energy and resources.