Re:Multilib/multiarch development on OpenBSD
on
OpenBSD 3.9 Released
·
· Score: 1
My code runs on 10 OSes, identically on all of them. The reason is because it is tested. There are numerous small differences between the various Unices that make careful testing a must. Anyone who has done any sort of portable coding will tell you the same thing. You need to quit talking out of your ass.
Re:Multilib/multiarch development on OpenBSD
on
OpenBSD 3.9 Released
·
· Score: 1
That's too bad. It dooms anyone who wants to support and test on both 32- and 64- bit to multiboot which is a half-baked solution and total PITA.
Re:Multilib/multiarch development on OpenBSD
on
OpenBSD 3.9 Released
·
· Score: 1
Anybody else got an opinion? Geekboy says its impossible. Meanwhile I have Ubuntu, FC5, SuSE and FreeBSD (all AMD64) up and running in my network in 32/64 bit multiarch form. I actually like testing my code before releasing it (in whatever form). If anyone knows how to do it in OpenBSD please let me know. Thanks.
Anybody know if OpenBSD 3.9 supports 32 and 64 bit development on the x64/AMD64 platform? I installed OpenBSD 3.8 and it only seemed to support 32 bit development on the i386 distro and 64 bit development on the x64 distro... but not both on the x64 distro. Any ideas?
Actually I had the exact opposite experience of GP. Running TYAN S2895 (K8WE) motherboard the SuSE 10.0 install worked through the first CD and then yast choked as soon as I inserted the second disk, spewing a bunch of MD5 checksum errors on packages it was trying to install. The disks were flawless (not corrupted) according to its own disk testing procedure. Never could figure out the problem but it probably has something to do with the hardware. (If you know what the solution is please let me know cause I'd love to be running SuSE).
Also consider another huge internationalization hairball, that of dates, times and DST coverage. DST is completely arbitrary and can vary from year to year, even based on political whim. Converting between different timezones correctly at DST boundries is a PITA as well.
By nuclear pile I mean nuclear power generation station. Sorry if I wasn't clear enough. This would only happen if the waste management and disposal issue has been resolved. And resolved means resolved not just "living with it". If you think solar power, or wind or even bovine flatulance will power the cities of the future you need to write the Department of Energy and give them your findings. Meanwhile I'll stick to my prediction (which conveniently neither of us will be alive to verify or disprove).
The future is in technology, nano, bio and nuclear. Manipulation of basic physical matter. Eventually the issues (like cleanup and safety) of fission reactors will be solved, and the stigma will wash away into distant memory as a new generation of lawmakers not "polluted" by memories of Chernobyl and Three Mile Island will inherit capital hill. This is of course in the absence of a major breakthrough producing a completely unknown alternate energy source. All the while the ultimate goal being the production of a true, commercialized fusion reactor.
I would expect inside of 100 years there will be miniturized nuclear piles dotting the landscape, dozens or even hundreds of them per state.
That this gets modded insightful is an embarrassment. Every DBA worth two shakes of a dead rats ass can tell you putting stored procedures in the DB cuts down on network traffic and improves application responsiveness. Every time a query is passed across the network it has to be compiled to p-code. Multiply that by X users and the system grinds to a halt. Ease of implementation and clarity also shoot through the roof with proper use of stored procedures. And the scalability problems you speak of don't exist, since you can instance your database just like your app server.
The Slashdot hive mind may not like the idea of being tied to a particular database or vendor but in the Real World businesses choose their databases carefully and stick with them for a long time, often forever. With this in mind you exploit every single option available when programming and stored procedures along with proper filesystem layout, column indexing and schema design are key to a high performance database.
Re:Thoughts on necessity of rogues in a group.
on
Rogues Get Some Respect
·
· Score: 2, Interesting
Its really hard to believe that this kind of customization can't be handled by typical MMOs, especially with the rise of instancing. You'd think they could take a party, weight their various stats, abilities and items and even keep a running log of their playing tendencies (ie which commands are used the most frequently) and customize the encounters and challenges based on these metrics. I guess they just haven't evolved to that point yet, although reading the article it sounds like DDO might be headed in that direction. The only way to cut through the cheerleading is to actually play it for a while.
What about that scheme can't be done in a GC language when needed in critical sections and abandoned when not? Sure it's ugly to do in those languages, but so's writing your own GC in a non-GC language (e.g. SmartPointers).
Never seen it done in any language other than C or C++. Perhaps it is possible in C# but you'd have to be in unsafe mode the whole time. I'd love to hear how its done. I've had the good fortune of building an incremental GC system in C integrated into a memory manager and it was tricky to get right but with time it became rock solid, so it can be done.
Incidentally, this is the sort of thing that your OS should be doing for you. No one pratically needs this level of control unless they're flying without a well-featured OS (i.e. working in an embedded context).
There are things the OS can do and there are things it can't. It would be nice for the OS to provide all relevent services but sometimes they just aren't there and other times for the sake of portability you have to manage it at the application level. This is more true for enterprise-class software than one-off hacks.
People pulling this sort of nonsense in a normal application are just setting themselves up for a fall.
I will agree that this is an arena for experts. Inexperienced or incompetent people will hang themselves when they wade in this deep. Look its all just memory anyways. What you do with it is up to you. If you consider C as a "high level assembly language" (which it is) then this kind of "nonsense" is par for the course and even expected. Would you rail against an assembly language programmer for doing this?? Don't fault the language for allowing it (or the expert for doing it) simply because it looks like your idea of a high level language.
Just don't complain when you're shopping around for a product and find one that has 5x the number of crashes and exploits of its GD'd competitors. Then you the customer are forced to pay the price for programmer obession with trying to optimize non-critical sections.
I disagree. You are describing a product with poor QA testing, not a defect inherent in manually managed memory. If you dislike unstable products blame the company foisting this piece of shite on the market. Its not a huge stretch to say software that is tested thoroughly tends to become more stable regardless of its memory management scheme. And I would hardly call memory alloc/free optimization non-critical. It is the single biggest (non-algorithm based) drain on processor time, beyond even synchronization.
Raw speed. Malloc a huge chunk of memory. Custom cut one or more items out of the huge chunk, manually managing byte alignment of the objects to ensure portability between different chipset architectures. This is what most people refer to as a "custom allocator" (possibly also a pool or slab allocator) and its performance is vastly higher than an equal number of new's in a GC language. But wait! You don't have to actually free anything once you're done (no memory leaks), you just do a bulk free of the original memory slab. Or not, you can just reuse the memory slab for a new group of objects. Manual memory management gives flexibility that no GC language ever will. If you don't need the flexibility then fine, you can use a GC language and reap the benefits. Just don't complain when you're shopping around for a product and find one that is 5x the speed of its GD'd competitors. Then you the customer are forced to pay the price for programmer laziness and/or convenience.
I was a big fan of old Gamma World. I still have a mint copy of the 1978 GW ruleset, including box. I always thought Legion of Gold was one of the 5 top modules ever produced in any gaming system, ever. Damn shame there were so few good modules available, really only GW1 and GW2 were of early AD&D module quality.
If you want to check out a really killer bit of old school GW fun Google for Bigfella Machine and check out the New West and New South.
Re:Write and test on three different platforms
on
Write Portable Code
·
· Score: 1
I agree. I built a 10+ meg library in C++, currently backporting to C. The thing runs identically and flawlessly in Win 4.0, Win 2k & 2k3, SCO Unix, Red Hat Linux, SuSE Linux, and Free BSD. Also preliminary tests indicate it compiles on Solaris 10 (SPARC) in 32 and 64 bit mode. I will be adding an RS/6000 Power-III box to the mix sometime early next year. Can't agree with you more: multiple boxes, different chipsets (PA-RISC, SPARC, POWER and x86), different void * sizes (32 and 64 bit) and operating systems. The key to my portability was heavy (but proper) use of typedef, #ifdef and creating OS level portability wrappers. Works like a charm and still fast as hell (especially in this day of byte code).
It is of interest that the first thing the Third Reich did during their ascent to power was defang the general population by confiscating their guns. I wonder when that'll come down the pipe.
I am in the same boat you are. After a 5 year startup project (which I pursued for 3 years in my spare time and 2 years full time) failed I wound up owning like 25,000 man hours worth of developer labor and a very lucrative product that is about 90% finished. My first instinct is to do a similar thing to what you have done - give out non-exclusive, royalty free source and runtime lisences to companies I work for with the stipulation that any work done at the level of my code (enhancements, bug fixes etc) is owned by me... period. I even have a pretty clear idea what the lisence will look like. Also eventually I suspect I'll take ownership of the product code and finish the product if I am able to. We'll see how it works out.
Frankly not too bad. OS X is what Microsoft wanted Longhorn to be. Stability? Check. Security? Check. Gorgeous Eye Candy? Check. Plug something in and it just works? Check. Easy for granny to use? Check. Powerful enuf for your average Unix hack? Check. Apple is sitting on a ball breaker of an OS and they know it. I think Steve Jobs senses MS for all its recent Longhorn misfires is at its weakest (OS wise) in probably a good two decades. He may swear up and down he will never let OS X run on just any PC and that may be true but notice that still doesn't rule out an OS X rollout on specially branded PCs built by hand picked suppliers (like Dell). Provided Apple gets a reasonable cut of the profits it sounds feasible. They make up in volume what they lose in direct sales and still get to uphold the Sterling Apple Brand and reputation that goes with it.
It's not just in the DC area. I'm out here in Fresno (central CA) and housing in this place is 2.5x what it was 7 years ago and growing at like 40% annually. Its absurd. A house I bought (and subsequently lost... bummer) for $133,000 in 1997 is now worth $350,000 apparently. Over here it has to do with the outflux from Silicon Valley to find cheaper housing. But I'm still convinced the whole housing market has turned into the.com boom of the 2000's. It's gonna crash, it has to.
Its interesting if you look at the responses in this topic 90% seem to be modded +5 funny. Except the argument Cringely makes isn't outlandish in the least. This move is too huge and too bizaare to be just randomly pulled out of someones ass. Today's Apple is a white-hot consumer brand; this after languishing in the backwaters for the better part of two decades. Intel with Apple as a wholly owned subsidiary would leave Bill Gate's eyes the size of dinner plates and Apple's shareholders laughing all the way to the bank. The entire industry would shift on its axis. I'm tempted to buy AMD stock because that's the first place MS would go to try to prop up their empire. I think we dismiss the tinfoil hat crowd here at our own risk.
Man I *knew* that term sounded familiar. For all youngsters out there you should get familiar with the Hacker's Dictionary. God forbid you start "inventing" slang that's been around since before you were born.
http://www.tf.hut.fi/cgi-bin/jargon?search=automag ically
Slashdot Mirror
My code runs on 10 OSes, identically on all of them. The reason is because it is tested. There are numerous small differences between the various Unices that make careful testing a must. Anyone who has done any sort of portable coding will tell you the same thing. You need to quit talking out of your ass.
That's too bad. It dooms anyone who wants to support and test on both 32- and 64- bit to multiboot which is a half-baked solution and total PITA.
Anybody else got an opinion? Geekboy says its impossible. Meanwhile I have Ubuntu, FC5, SuSE and FreeBSD (all AMD64) up and running in my network in 32/64 bit multiarch form. I actually like testing my code before releasing it (in whatever form). If anyone knows how to do it in OpenBSD please let me know. Thanks.
Anybody know if OpenBSD 3.9 supports 32 and 64 bit development on the x64/AMD64 platform? I installed OpenBSD 3.8 and it only seemed to support 32 bit development on the i386 distro and 64 bit development on the x64 distro... but not both on the x64 distro. Any ideas?
Actually I had the exact opposite experience of GP. Running TYAN S2895 (K8WE) motherboard the SuSE 10.0 install worked through the first CD and then yast choked as soon as I inserted the second disk, spewing a bunch of MD5 checksum errors on packages it was trying to install. The disks were flawless (not corrupted) according to its own disk testing procedure. Never could figure out the problem but it probably has something to do with the hardware. (If you know what the solution is please let me know cause I'd love to be running SuSE).
Also consider another huge internationalization hairball, that of dates, times and DST coverage. DST is completely arbitrary and can vary from year to year, even based on political whim. Converting between different timezones correctly at DST boundries is a PITA as well.
By nuclear pile I mean nuclear power generation station. Sorry if I wasn't clear enough. This would only happen if the waste management and disposal issue has been resolved. And resolved means resolved not just "living with it". If you think solar power, or wind or even bovine flatulance will power the cities of the future you need to write the Department of Energy and give them your findings. Meanwhile I'll stick to my prediction (which conveniently neither of us will be alive to verify or disprove).
I would expect inside of 100 years there will be miniturized nuclear piles dotting the landscape, dozens or even hundreds of them per state.
The Slashdot hive mind may not like the idea of being tied to a particular database or vendor but in the Real World businesses choose their databases carefully and stick with them for a long time, often forever. With this in mind you exploit every single option available when programming and stored procedures along with proper filesystem layout, column indexing and schema design are key to a high performance database.
Its really hard to believe that this kind of customization can't be handled by typical MMOs, especially with the rise of instancing. You'd think they could take a party, weight their various stats, abilities and items and even keep a running log of their playing tendencies (ie which commands are used the most frequently) and customize the encounters and challenges based on these metrics. I guess they just haven't evolved to that point yet, although reading the article it sounds like DDO might be headed in that direction. The only way to cut through the cheerleading is to actually play it for a while.
You've clearly never worked as an OBGYN or Surgery nurse.
Does anyone remember the Albuquerque Star Port module in the Gamma World Referee's Screen from circa 1980? This is just too weird.
Never seen it done in any language other than C or C++. Perhaps it is possible in C# but you'd have to be in unsafe mode the whole time. I'd love to hear how its done. I've had the good fortune of building an incremental GC system in C integrated into a memory manager and it was tricky to get right but with time it became rock solid, so it can be done.
Incidentally, this is the sort of thing that your OS should be doing for you. No one pratically needs this level of control unless they're flying without a well-featured OS (i.e. working in an embedded context).
There are things the OS can do and there are things it can't. It would be nice for the OS to provide all relevent services but sometimes they just aren't there and other times for the sake of portability you have to manage it at the application level. This is more true for enterprise-class software than one-off hacks.
People pulling this sort of nonsense in a normal application are just setting themselves up for a fall.
I will agree that this is an arena for experts. Inexperienced or incompetent people will hang themselves when they wade in this deep. Look its all just memory anyways. What you do with it is up to you. If you consider C as a "high level assembly language" (which it is) then this kind of "nonsense" is par for the course and even expected. Would you rail against an assembly language programmer for doing this?? Don't fault the language for allowing it (or the expert for doing it) simply because it looks like your idea of a high level language.
Just don't complain when you're shopping around for a product and find one that has 5x the number of crashes and exploits of its GD'd competitors. Then you the customer are forced to pay the price for programmer obession with trying to optimize non-critical sections.
I disagree. You are describing a product with poor QA testing, not a defect inherent in manually managed memory. If you dislike unstable products blame the company foisting this piece of shite on the market. Its not a huge stretch to say software that is tested thoroughly tends to become more stable regardless of its memory management scheme. And I would hardly call memory alloc/free optimization non-critical. It is the single biggest (non-algorithm based) drain on processor time, beyond even synchronization.
Raw speed. Malloc a huge chunk of memory. Custom cut one or more items out of the huge chunk, manually managing byte alignment of the objects to ensure portability between different chipset architectures. This is what most people refer to as a "custom allocator" (possibly also a pool or slab allocator) and its performance is vastly higher than an equal number of new's in a GC language. But wait! You don't have to actually free anything once you're done (no memory leaks), you just do a bulk free of the original memory slab. Or not, you can just reuse the memory slab for a new group of objects. Manual memory management gives flexibility that no GC language ever will. If you don't need the flexibility then fine, you can use a GC language and reap the benefits. Just don't complain when you're shopping around for a product and find one that is 5x the speed of its GD'd competitors. Then you the customer are forced to pay the price for programmer laziness and/or convenience.
If you want to check out a really killer bit of old school GW fun Google for Bigfella Machine and check out the New West and New South.
I agree. I built a 10+ meg library in C++, currently backporting to C. The thing runs identically and flawlessly in Win 4.0, Win 2k & 2k3, SCO Unix, Red Hat Linux, SuSE Linux, and Free BSD. Also preliminary tests indicate it compiles on Solaris 10 (SPARC) in 32 and 64 bit mode. I will be adding an RS/6000 Power-III box to the mix sometime early next year. Can't agree with you more: multiple boxes, different chipsets (PA-RISC, SPARC, POWER and x86), different void * sizes (32 and 64 bit) and operating systems. The key to my portability was heavy (but proper) use of typedef, #ifdef and creating OS level portability wrappers. Works like a charm and still fast as hell (especially in this day of byte code).
Shhhh... That kind of logic won't register around these parts. Its just "scratching an itch", they're not being exploited. To the hilt.
1. Leak an easily breakable x86 copy of OS X onto the internet.
2. Watch as it gets pirated to the nth degree.
3. Sit back and laugh as everyone gets attuned to using OS X and marvels at its quality, eye candy and stability.
4. Release a locked down version that runs only on Apple x86 hardware.
5. Watch as droves of people go to pick up your hardware after becoming hopelessly addicted to the OS.
6. (note lack of ???) Profit.
That is a seriously good game with an endless number of options. Too bad it doesn't randomly generate the map each time you play though.
It is of interest that the first thing the Third Reich did during their ascent to power was defang the general population by confiscating their guns. I wonder when that'll come down the pipe.
I am in the same boat you are. After a 5 year startup project (which I pursued for 3 years in my spare time and 2 years full time) failed I wound up owning like 25,000 man hours worth of developer labor and a very lucrative product that is about 90% finished. My first instinct is to do a similar thing to what you have done - give out non-exclusive, royalty free source and runtime lisences to companies I work for with the stipulation that any work done at the level of my code (enhancements, bug fixes etc) is owned by me... period. I even have a pretty clear idea what the lisence will look like. Also eventually I suspect I'll take ownership of the product code and finish the product if I am able to. We'll see how it works out.
Frankly not too bad. OS X is what Microsoft wanted Longhorn to be. Stability? Check. Security? Check. Gorgeous Eye Candy? Check. Plug something in and it just works? Check. Easy for granny to use? Check. Powerful enuf for your average Unix hack? Check. Apple is sitting on a ball breaker of an OS and they know it. I think Steve Jobs senses MS for all its recent Longhorn misfires is at its weakest (OS wise) in probably a good two decades. He may swear up and down he will never let OS X run on just any PC and that may be true but notice that still doesn't rule out an OS X rollout on specially branded PCs built by hand picked suppliers (like Dell). Provided Apple gets a reasonable cut of the profits it sounds feasible. They make up in volume what they lose in direct sales and still get to uphold the Sterling Apple Brand and reputation that goes with it.
It's not just in the DC area. I'm out here in Fresno (central CA) and housing in this place is 2.5x what it was 7 years ago and growing at like 40% annually. Its absurd. A house I bought (and subsequently lost... bummer) for $133,000 in 1997 is now worth $350,000 apparently. Over here it has to do with the outflux from Silicon Valley to find cheaper housing. But I'm still convinced the whole housing market has turned into the .com boom of the 2000's. It's gonna crash, it has to.
Its interesting if you look at the responses in this topic 90% seem to be modded +5 funny. Except the argument Cringely makes isn't outlandish in the least. This move is too huge and too bizaare to be just randomly pulled out of someones ass. Today's Apple is a white-hot consumer brand; this after languishing in the backwaters for the better part of two decades. Intel with Apple as a wholly owned subsidiary would leave Bill Gate's eyes the size of dinner plates and Apple's shareholders laughing all the way to the bank. The entire industry would shift on its axis. I'm tempted to buy AMD stock because that's the first place MS would go to try to prop up their empire. I think we dismiss the tinfoil hat crowd here at our own risk.
Man I *knew* that term sounded familiar. For all youngsters out there you should get familiar with the Hacker's Dictionary. God forbid you start "inventing" slang that's been around since before you were born. http://www.tf.hut.fi/cgi-bin/jargon?search=automag ically