You really have no understanding of the problem, do you? The complete commodification of the rights to pollute simply mean that companies will simply find a way to price in the dollar value of pollution credits to get away with whatever they are doing now.
Most of your points well taken. However, this last is a strawman argument, as carbon offsets != carbon credits. Carbon credits would be somewhat equivalent to what the OP's tax revenue would have bought (note that his tax on the fossil fuels themselves translates into a consumption-proportional quantity... a clever adaptation that I don't think he put a great deal of thought into). In the U.S., our current system of government regulated credits has resulted in exactly what you say, above. However, if credits were not purchased, but instead offsets are purchased, then ton for ton, the actual CO2 released during fossil fuel consumption would be absorbed or simply not generated somewhere else in the world. For example, in the Pacific northwest of the United States, a large power co-op has run a program called BlueSky that allows one to purchase the right to commit the utility to buy (100kWh) blocks of energy from wind sources. They would have produced that energy via oil/gas/coal/whatever. So, the cost paid to commit them to a wind source, offsets other carbon production in your life.
Of course, as I said right off, points about sinking carbon are well taken. I have zero faith in carbon sinking, at this point, to provide a viable, quantifiable, offset. I think that at this point, alternative power generation is the only path forward that can be metered with any confidence.
Also, this would provide the market incentive for industry to improve the efficiency of power generation. If an (at least) national market for independant alternative power generation was funded under the auspices of carbon offsets, then market entities would compete for a slice of carbon pie. Whomever can generate the highest cost per carbon-free megawatt would contract up to their capacity. It would be easy to administer and regulate for honesty too, all you'd have to do is verify; 1) did they secretly use fossil fuels? 2) did they generate N megawatts?
Of course, Congress would be in charge of setting & updating the fossil fuel tax rate, which should be fairly fixed, as there is (correct me if I'm wrong here) a fixed amount of releasable CO2 in each fuel molecule, no? So, the the rate would have to be proportional (somehow) to the market rate of energy offsets. If the market is big enough, it could trade as a commodity.
A virus goes around, waiting to fall into some foreign body where it can infiltrate a cell and turn the cell's work against the foreign body to produce and spread more virus. See the analogy?
The GPL, OTOH, doesn't turn other existing software into GPL.
So, other than the BSD (and other essentially public-domain code with hardly any protections to speak of), it's true the the GPL affects new code development primarily.
Interesting. It seems the GPL takes "base materials" (non-code, such as time, programmers, coffee, etc.) and turns it into more GPL code. So, the GPL is really more bacterial than viral. It spreads, and clones slight variants, etc, but it doesn't make non-GPL code into GPL code, so it really can't be viral.
Make money off of mods to the code itself, not the use of a complete & distributed package. In GPL parlance, if you didn't link any object code to any other object code using a linker (or the functional equivalent for interpreted languages). If you modify python itself and run your site off it (my own private Mython!!! Yay!) then you can't go sell Mython.
If you already understood that part of it, and were simply pointing out that "you can't profit off others without giving something back" was fallacious, then either you or the grandparent poster is being pedantic.
My statement regarding student gamer above would be that probably wouldn't have finished his $5 game without the libraries to begin with, so where was the loss? He'd either have had to spend time or money to get where he was by writing his own libraries or buying them and consequently charge a lot more, or needs to sell his $5 game after a short dev cycle & comply with GPL (if he's smart, the library would be SDL, and the LGPL is in affect, as other posters have mentioned).
I see no inconsistency here, nor any real argument against the GPL or using it. Is he suggesting that someone might somehow be "tricked" by the daemons into using GPL code and then "oh noes!!" Solution there is to be a smarter programmer, period. Be aware of the licenses of other people's code you use. Perhaps the state of modern licensing has forced us coders to spend some cycles and brain cells on legal crap now. If so, then you have a choice. Understand your licensing, or rely on "faith-based liability protection."
Exactly. The symbols we use are representational; they are a notation based solely on convention (yes, between hundreds and thousands of years of convention, tradition and history, but who's counting?).
It's just as important that our maths be independent of representation as it is that we use clear, concise symbology. So it is vital for understanding that we use the correct symbols (and logic in the sentence structure of our proofs), and it is crucial that the choice of individual symbols be arbitrary and inherently meaningless, such that the results are always well-defined.
Transparent rolling film: works for NASCAR cameras, but film may tear or get caught in winding mechanism....
Not to mention that a failure mode where it's fully deployed over the panel and then sticks. I'm not sure what sort of power generation can be expected with a thin translucent plastic film covering the panels.
So, the first time that happens, you walk over with her, and retrain it for her thumb. BIG DEAL. Until she cuts her thumb, then you help her train it for the other thumb, etc.
If you have a fingerless daughter, train it to her toes (and retrain as above, when Strawberry Shortcake makes her rounds amongst the little piggies).
If you have a fingerless, toeless daughter who wants to use the computer anyway, for fucks sake, memorize her password for her, you heartless clod!
Absurd. The day her fingerpress stops working, you fire up the trainer again and retrain the sensor. Imagine that instead of generating & memorizing a new random password 3-4 times a year, you just retrain your fingerprint sensor twice a year. If you are the parent, and you have root access (I would say necessary, unless your young daughter is a whiz with resolving package dependency collisions, hand updating binary graphics card drivers, or migrating data to bigger faster hard drives after reparitioning them), then you can always log in and retrain her thumbprint.
I think what he wants is a Cherry Smartboard FingerTIP USB keyboard. It's ungodly expensive, but cross-platform and uses a nice sensor (which doesn't depend on only the fingerprint itself, rather, other dermal characteristics, like blood vessel patterns & such).
In previous life, I worked with a company that built small portable Linux computers with biometric authentication (the vendor was Authentec, I think). They did not use the print, though they did use the finger impression. You would press it a certain way during the training phase, and repeat several times. I always encouraged others not to concentrate very hard on doing it exactly the same way every time, so that the recorded impression had a broader range. It used a variety of biometrics, including a sensitivity related to the unique pattern of dermal capillaries (IANAMD, but I read the product literature). So, "lifted" prints are useless on good biometric print scanners. In general, swipe scanners are better (the little bar-shaped things on laptops, Thinkpads, for example) are pretty good, and usually use this sort of technology. Those models don't necessarily read the finger print itself, due to the shape and size of the sensor, or at least use more than just the print.
Authentec is expensive tech, though. You might do better looking for used products that contain them, and hacking those into some sort of authentication station. Our code used a PAM module, and worked really well. It would prompt you, do the read through some external, closed-source, vendor-supplied, binary blob (external as in not linked, so as to not violate GPL), you'd do your finger press, and it would authenticate you.
Perhaps some other company has already productized a biometric authentication peripheral (I'm thinking USB), with a software SDK. Perhaps an eval kit from Authentec would do the trick; I bet they'd bundle the solib with the eval kit.
I particularly remember that it was fussy about the way you pressed the sensor; you kind of had to learn how to do it every time; if you press it upside down or a bit sideways and it wouldn't recognize you. So, it required a kind of physicial-dexterity-memory thing. The sort of thing, I would say, that a child is very very good at learning.
Best of all, since it was a generic PAM module, there is no reason that multiple persons couldn't be authenticated and logged into their own account. So, each family member could access a shared workstation with biometric credentials. Perhaps yours are root's. Or perhaps you configure your system to only permit console root logins via biometric authentication, and remote root logins by ssh agent keys; no more passwords! Just biometrics or your passphrase.
Might be tough for the resident eggheads to spec, build & support a cluster of over 1100 nodes. How many MSCEs and MSCITPs know how to properly rack up & cool that much hardware?
No. They tell everyone at the same time. Why? Well, those with investments in the company (stocks & options) will be watched prior to the sale by the SEC for evidence of "speculative trading" (that's what I like to call "insider trading"). A multi-hundred-million dollar buyout is a big deal and moves slowly. Be sure that the execs and the BOD have been cooking this up for months. I believe Postini is privately held, which makes the sale easier, but there is still the opportunity for all sorts of insider behaviour (speculation on how this could affect their publicly-traded clients, and trades based on that knowledge, etc., etc...)
I suppose simulation is your only resort for component modules in the hardware design, so the BBT is really more of an integration-testing effort. You're right, however, internal clocking and timing issues are awfully difficult to diagnose... it's not like we can get down there and probe a particular layer and measure the hold times as the clock settles. We can't really even bring out test points (which at least you can synthesize into FPGA designs). Though, it's not like you're actually verifying each of 200 million transistors. I disagree with your scaling statement on the feature count; feature count isn't increasing with Moore's law, it's the transistor count. Our diagnostic techniques will certainly improve. It's not like semiconductor manufacturing has to start over on every chip, every revision, every decrease in nanometer/fabrication process.
The only reason (that I can see) that Intel & AMD profit from flawed designs is because the consumer is lazy or doesn't care, or both. It's a demand-driven problem. If consumers demanded quality, the number of testing & respin cycles will increase to equilibrium.
Many things can't be testing with blackbox testing dumbass
Eh??? How exactly do you think many of those errata items were discovered and reported to Intel? By hard-working hordes of programmers like us who just happened to be performing static analysis on Intel's super-secret Verilog and RTL??
It would probably be more accurate to say "Many things can't be testing [sic] with simulation only dumbass." Besides, when the API to the "new system of doing things" would be used to write a (software) unit test, and as such the implementation of the "new system of doing things" in the CPU is abstracted out of the test completely (hence the blackboxness of it all).
Perhaps blackbox testing is an incomplete tool for FIXING hardware flaws & errors, but certainly it's the ideal technique for a first pass at FINDING them.
Click 'search' again. The box will appear. It didn't on a search from the home page, for me, but a search from the second-tier search causes the box to appear.
I'll testify to Cold War and the whole Neverwinter Nights catalog. Not to mention the, what, four or five premium modules, all of which play on Linux? There's a lot of game there (not including the massive community expansion packs and additional community generated content).
I'm still sore about NWN2, and I worry that Atari/Obsidian's treatment of the community contributors will result in a smaller community of content creators, and thusly less popularity for the game in general. Which would mean no NWN3 (or not a very big effort), and sure as hell no NWN3 for Linux.
Right on the point. I'd mod up if I could, and agree on all points. Add to the list of playable games anything that Icculus is spending 150% of his time developing/porting/maintaining.
Nope, it's pretty clear from the article that that logos and associated graphics are the issue. Trademark use conditions require that they be included. The Debian Free Software Guidelines require that they not be included. Thus, Mozilla Corporation postures some, and also attaches other strings; like the patch review & description, tagged subversion branch, prior approval of build conditions themselves, and inclusion of said graphics.
I agree with the rest of your statement, though, and I do think that this business is a big waste of developer time and effort. Now it is really more difficult to comply adequately, depending on the nature and volume of Debian's patches.
If one were to invite prognostication from me, I'd say that this sort of response will grow, as Mozilla Corporation flexes it's muscle over trademark enforcement. I'd guess that Debian, Ubuntu, and any other distro striving to be truly free, will probably do something like perform conditions 1 and 3 anyway (publicly submit patches w/descriptions, as well as tag their divergent branch), will probably exert the GPL and use whatever build time configurations they think are best, and lastly, come up with their own artwork and graphics.
That will further their goal of using & distributing free, high-quality software (without non-free strings attached to binary data included in the final product) to their users. My guess is that creative icon-ing will make this change remarkeably less noticeable to end users. After all, there is no reason that iceweasel (et. al.) couldn't use the same (or similar) versioning and advertise itself as being 'firefox compatible' as far as extensions & page rendering go. Not to mention, that I seriously doubt it would be a violation of trademark to install a 'firefox', or 'mozilla-firefox' symbolic link (in a very/etc/alternatives sort of way). In Debian and Ubuntu, it would be the 'sensible-browser', most likely. Folks could always still just go download the shell-archive installer from mozilla.org any time they want to and drop their own out-of-package-management version of the one true firefox.
On the side of Mozilla Corp., they will either decide that this dilutes the brand, and just bend to unify everyone, or they won't care and will drop strictly-all-free sorts of GNU/Linux distributions, assuming that the market share they bring is minimal.
And that will be that. Just my guess, anyway. If Mozilla Corp is smart, they'll exclude the user-agent string from trademark issues so that at least usage statistics will show a unified product, rather ruining firefox's growing usage statistics rank in a schism.
Agreed. The vendor is not always the best support provider. For example, one of the reasons that microsoft is so successful in providing "support" is that they have so many "certified" solution providers. Commercial software houses that try to rely on microsoft for software dev support (in my experience) end up sorely disappointed. Being able to contract out the support/bug fixing in a bid process can bring better prices. There's not reason that a third party couldn't provide adequate development support for an open source product.
The OP also seemed to be rolling all of support in the enterprise into the same support goal; like why waste money at all on vendor support for the dev workstations? That's ludicrous. You know they'll eventually need an IT person to maintain their windows workstations, even if microsoft is providing security patches. That person can do desktop support, and if they are competent, likely get better results faster than a commercial support vendor.
It sounds to me that the problem for this startup was more an issue of lack of leadership at the executive level with strong personal experience in open source embedded development. From the pricing, I'm pretty sure I know which RT linux vendor they went with, and if so, "reputable" was likely not evaluated from a developer standpoint. I would probably say that the "not want to spend time for any OSS bug fixing" attitude is the problem. I'd rather a platform with *all* the code PLUS noncommercial support any day over code+commercial support, or (worse) just the support. It's making a big assumption that somehow the commercial product is going to come bug free and that support is going to snap a patch out to you by the end of the week (or sooner).
I would say a shop running less than 10 devs is probably not going to get that level of attention from a commercial vendor, but who knows? Maybe they will. I'm sure that the OP will come back in six months and tell us all about how csharp, visual studio, and windows ce saved the day. ROI! TCO! Rah rah rah!
Yep. I was actually paid by my last employer for a couple of weeks to debug & plug memory leaks in poppler that I found profiling it in valgrind. I found two, one that was really bad, and one that wasn't so bad. It's really tough to do because PDF's are so damned complex. While there are many levels of indirection in the poppler/xpdf rendering code, it seems to be decently written, with a few exceptions. Memory is allocated in both the C++ and C way, and metadata specifying the method by which a chunk of memory is allocated is maintained with the allocated chunk. This is abstracted out so that there is (often) a single "smart" free() type of call that chooses the correct way to release/handle the memory (free or delete, realloc, etc).
To make things worse, there is a relatively sophisticated (to me!) caching subsystem that tricks valgrind into some false positives on leakage, so those had to be identified from the memory run traces. It was a mess.
Anyway, lots instantiations are flying around, so you end up matching pointer allocation/freeing and it's tedious. Unfortunately my company got cut in half before I finished, and I ended up in the half that needed new employment. I had just started playing with the memory debugging defines that are in the code, but they didn't seem to be terribly helpful for the particular leaks that I identified.
I'll probably go back some day and try to track down & finish my work, on my own time, but I'm not in any big hurry because debugging gui-library memory interactions for subtle memory leaks is not exactly the most fun open source side project. I personally can only do that for perhaps 2-3 hours at a time before my brain wants to completely shut down, or leave my head and drink scotch (or both).
I sincerely hope that I'm not the only with half-hearted interest in actually fixing memory utilization in that lib... that would be depressing. The project maintainer looks overworked and seems to be focusing on fixing crasholas and rendering bugs. At that rate, I seriously doubt he'll *ever* get to memory leaks.
Slashdot Mirror
So, you're saying that when your obsession causes you to fill your two gaping holes, it makes you feel dirty?
;-)
Further, that you've only ever made it through 30m of the video? Twice?
Sure you aren't talking about another industry?
Just saying...
You really have no understanding of the problem, do you? The complete commodification of the rights to pollute simply mean that companies will simply find a way to price in the dollar value of pollution credits to get away with whatever they are doing now.
Most of your points well taken. However, this last is a strawman argument, as carbon offsets != carbon credits. Carbon credits would be somewhat equivalent to what the OP's tax revenue would have bought (note that his tax on the fossil fuels themselves translates into a consumption-proportional quantity... a clever adaptation that I don't think he put a great deal of thought into). In the U.S., our current system of government regulated credits has resulted in exactly what you say, above. However, if credits were not purchased, but instead offsets are purchased, then ton for ton, the actual CO2 released during fossil fuel consumption would be absorbed or simply not generated somewhere else in the world. For example, in the Pacific northwest of the United States, a large power co-op has run a program called BlueSky that allows one to purchase the right to commit the utility to buy (100kWh) blocks of energy from wind sources. They would have produced that energy via oil/gas/coal/whatever. So, the cost paid to commit them to a wind source, offsets other carbon production in your life.Of course, as I said right off, points about sinking carbon are well taken. I have zero faith in carbon sinking, at this point, to provide a viable, quantifiable, offset. I think that at this point, alternative power generation is the only path forward that can be metered with any confidence.
Also, this would provide the market incentive for industry to improve the efficiency of power generation. If an (at least) national market for independant alternative power generation was funded under the auspices of carbon offsets, then market entities would compete for a slice of carbon pie. Whomever can generate the highest cost per carbon-free megawatt would contract up to their capacity. It would be easy to administer and regulate for honesty too, all you'd have to do is verify; 1) did they secretly use fossil fuels? 2) did they generate N megawatts?
Of course, Congress would be in charge of setting & updating the fossil fuel tax rate, which should be fairly fixed, as there is (correct me if I'm wrong here) a fixed amount of releasable CO2 in each fuel molecule, no? So, the the rate would have to be proportional (somehow) to the market rate of energy offsets. If the market is big enough, it could trade as a commodity.
A virus goes around, waiting to fall into some foreign body where it can infiltrate a cell and turn the cell's work against the foreign body to produce and spread more virus. See the analogy?
The GPL, OTOH, doesn't turn other existing software into GPL.
So, other than the BSD (and other essentially public-domain code with hardly any protections to speak of), it's true the the GPL affects new code development primarily.
Interesting. It seems the GPL takes "base materials" (non-code, such as time, programmers, coffee, etc.) and turns it into more GPL code. So, the GPL is really more bacterial than viral. It spreads, and clones slight variants, etc, but it doesn't make non-GPL code into GPL code, so it really can't be viral.
Make money off of mods to the code itself, not the use of a complete & distributed package. In GPL parlance, if you didn't link any object code to any other object code using a linker (or the functional equivalent for interpreted languages). If you modify python itself and run your site off it (my own private Mython!!! Yay!) then you can't go sell Mython.
If you already understood that part of it, and were simply pointing out that "you can't profit off others without giving something back" was fallacious, then either you or the grandparent poster is being pedantic.
My statement regarding student gamer above would be that probably wouldn't have finished his $5 game without the libraries to begin with, so where was the loss? He'd either have had to spend time or money to get where he was by writing his own libraries or buying them and consequently charge a lot more, or needs to sell his $5 game after a short dev cycle & comply with GPL (if he's smart, the library would be SDL, and the LGPL is in affect, as other posters have mentioned).
I see no inconsistency here, nor any real argument against the GPL or using it. Is he suggesting that someone might somehow be "tricked" by the daemons into using GPL code and then "oh noes!!" Solution there is to be a smarter programmer, period. Be aware of the licenses of other people's code you use. Perhaps the state of modern licensing has forced us coders to spend some cycles and brain cells on legal crap now. If so, then you have a choice. Understand your licensing, or rely on "faith-based liability protection."
Ever reinstalled from scratch?
Exactly. The symbols we use are representational; they are a notation based solely on convention (yes, between hundreds and thousands of years of convention, tradition and history, but who's counting?).
It's just as important that our maths be independent of representation as it is that we use clear, concise symbology. So it is vital for understanding that we use the correct symbols (and logic in the sentence structure of our proofs), and it is crucial that the choice of individual symbols be arbitrary and inherently meaningless, such that the results are always well-defined.
See?
In this way, maths are like Zen Buddhism.
Not to mention that a failure mode where it's fully deployed over the panel and then sticks. I'm not sure what sort of power generation can be expected with a thin translucent plastic film covering the panels.
So, the first time that happens, you walk over with her, and retrain it for her thumb. BIG DEAL. Until she cuts her thumb, then you help her train it for the other thumb, etc.
If you have a fingerless daughter, train it to her toes (and retrain as above, when Strawberry Shortcake makes her rounds amongst the little piggies).
If you have a fingerless, toeless daughter who wants to use the computer anyway, for fucks sake, memorize her password for her, you heartless clod!
Absurd. The day her fingerpress stops working, you fire up the trainer again and retrain the sensor. Imagine that instead of generating & memorizing a new random password 3-4 times a year, you just retrain your fingerprint sensor twice a year. If you are the parent, and you have root access (I would say necessary, unless your young daughter is a whiz with resolving package dependency collisions, hand updating binary graphics card drivers, or migrating data to bigger faster hard drives after reparitioning them), then you can always log in and retrain her thumbprint.
I think what he wants is a Cherry Smartboard FingerTIP USB keyboard. It's ungodly expensive, but cross-platform and uses a nice sensor (which doesn't depend on only the fingerprint itself, rather, other dermal characteristics, like blood vessel patterns & such).
In previous life, I worked with a company that built small portable Linux computers with biometric authentication (the vendor was Authentec, I think). They did not use the print, though they did use the finger impression. You would press it a certain way during the training phase, and repeat several times. I always encouraged others not to concentrate very hard on doing it exactly the same way every time, so that the recorded impression had a broader range. It used a variety of biometrics, including a sensitivity related to the unique pattern of dermal capillaries (IANAMD, but I read the product literature). So, "lifted" prints are useless on good biometric print scanners. In general, swipe scanners are better (the little bar-shaped things on laptops, Thinkpads, for example) are pretty good, and usually use this sort of technology. Those models don't necessarily read the finger print itself, due to the shape and size of the sensor, or at least use more than just the print.
Authentec is expensive tech, though. You might do better looking for used products that contain them, and hacking those into some sort of authentication station. Our code used a PAM module, and worked really well. It would prompt you, do the read through some external, closed-source, vendor-supplied, binary blob (external as in not linked, so as to not violate GPL), you'd do your finger press, and it would authenticate you.
Perhaps some other company has already productized a biometric authentication peripheral (I'm thinking USB), with a software SDK. Perhaps an eval kit from Authentec would do the trick; I bet they'd bundle the solib with the eval kit.
I particularly remember that it was fussy about the way you pressed the sensor; you kind of had to learn how to do it every time; if you press it upside down or a bit sideways and it wouldn't recognize you. So, it required a kind of physicial-dexterity-memory thing. The sort of thing, I would say, that a child is very very good at learning.
Best of all, since it was a generic PAM module, there is no reason that multiple persons couldn't be authenticated and logged into their own account. So, each family member could access a shared workstation with biometric credentials. Perhaps yours are root's. Or perhaps you configure your system to only permit console root logins via biometric authentication, and remote root logins by ssh agent keys; no more passwords! Just biometrics or your passphrase.
Might be tough for the resident eggheads to spec, build & support a cluster of over 1100 nodes. How many MSCEs and MSCITPs know how to properly rack up & cool that much hardware?
Maybe the same stuff the HAMMER was made of? Maybe not.
Such as? Only F/OSS examples, and only situations of full license compliance, please.
No. They tell everyone at the same time. Why? Well, those with investments in the company (stocks & options) will be watched prior to the sale by the SEC for evidence of "speculative trading" (that's what I like to call "insider trading"). A multi-hundred-million dollar buyout is a big deal and moves slowly. Be sure that the execs and the BOD have been cooking this up for months. I believe Postini is privately held, which makes the sale easier, but there is still the opportunity for all sorts of insider behaviour (speculation on how this could affect their publicly-traded clients, and trades based on that knowledge, etc., etc...)
I suppose simulation is your only resort for component modules in the hardware design, so the BBT is really more of an integration-testing effort. You're right, however, internal clocking and timing issues are awfully difficult to diagnose... it's not like we can get down there and probe a particular layer and measure the hold times as the clock settles. We can't really even bring out test points (which at least you can synthesize into FPGA designs). Though, it's not like you're actually verifying each of 200 million transistors. I disagree with your scaling statement on the feature count; feature count isn't increasing with Moore's law, it's the transistor count. Our diagnostic techniques will certainly improve. It's not like semiconductor manufacturing has to start over on every chip, every revision, every decrease in nanometer/fabrication process.
The only reason (that I can see) that Intel & AMD profit from flawed designs is because the consumer is lazy or doesn't care, or both. It's a demand-driven problem. If consumers demanded quality, the number of testing & respin cycles will increase to equilibrium.
Many things can't be testing with blackbox testing dumbass
Eh??? How exactly do you think many of those errata items were discovered and reported to Intel? By hard-working hordes of programmers like us who just happened to be performing static analysis on Intel's super-secret Verilog and RTL??
It would probably be more accurate to say "Many things can't be testing [sic] with simulation only dumbass." Besides, when the API to the "new system of doing things" would be used to write a (software) unit test, and as such the implementation of the "new system of doing things" in the CPU is abstracted out of the test completely (hence the blackboxness of it all).
Perhaps blackbox testing is an incomplete tool for FIXING hardware flaws & errors, but certainly it's the ideal technique for a first pass at FINDING them.
The best (biased) M$->SCO analysis. Pins Mike Anderer directly on the donkey...
m l
http://www.catb.org/~esr/halloween/halloween10.ht
Click 'search' again. The box will appear. It didn't on a search from the home page, for me, but a search from the second-tier search causes the box to appear.
Pretty please?
With gigs of flash on top??
I'll testify to Cold War and the whole Neverwinter Nights catalog. Not to mention the, what, four or five premium modules, all of which play on Linux? There's a lot of game there (not including the massive community expansion packs and additional community generated content).
I'm still sore about NWN2, and I worry that Atari/Obsidian's treatment of the community contributors will result in a smaller community of content creators, and thusly less popularity for the game in general. Which would mean no NWN3 (or not a very big effort), and sure as hell no NWN3 for Linux.
Dammit.
Right on the point. I'd mod up if I could, and agree on all points. Add to the list of playable games anything that Icculus is spending 150% of his time developing/porting/maintaining.
Nope, it's pretty clear from the article that that logos and associated graphics are the issue. Trademark use conditions require that they be included. The Debian Free Software Guidelines require that they not be included. Thus, Mozilla Corporation postures some, and also attaches other strings; like the patch review & description, tagged subversion branch, prior approval of build conditions themselves, and inclusion of said graphics.
/etc/alternatives sort of way). In Debian and Ubuntu, it would be the 'sensible-browser', most likely. Folks could always still just go download the shell-archive installer from mozilla.org any time they want to and drop their own out-of-package-management version of the one true firefox.
I agree with the rest of your statement, though, and I do think that this business is a big waste of developer time and effort. Now it is really more difficult to comply adequately, depending on the nature and volume of Debian's patches.
If one were to invite prognostication from me, I'd say that this sort of response will grow, as Mozilla Corporation flexes it's muscle over trademark enforcement. I'd guess that Debian, Ubuntu, and any other distro striving to be truly free, will probably do something like perform conditions 1 and 3 anyway (publicly submit patches w/descriptions, as well as tag their divergent branch), will probably exert the GPL and use whatever build time configurations they think are best, and lastly, come up with their own artwork and graphics.
That will further their goal of using & distributing free, high-quality software (without non-free strings attached to binary data included in the final product) to their users. My guess is that creative icon-ing will make this change remarkeably less noticeable to end users. After all, there is no reason that iceweasel (et. al.) couldn't use the same (or similar) versioning and advertise itself as being 'firefox compatible' as far as extensions & page rendering go. Not to mention, that I seriously doubt it would be a violation of trademark to install a 'firefox', or 'mozilla-firefox' symbolic link (in a very
On the side of Mozilla Corp., they will either decide that this dilutes the brand, and just bend to unify everyone, or they won't care and will drop strictly-all-free sorts of GNU/Linux distributions, assuming that the market share they bring is minimal.
And that will be that. Just my guess, anyway. If Mozilla Corp is smart, they'll exclude the user-agent string from trademark issues so that at least usage statistics will show a unified product, rather ruining firefox's growing usage statistics rank in a schism.
Agreed. The vendor is not always the best support provider. For example, one of the reasons that microsoft is so successful in providing "support" is that they have so many "certified" solution providers. Commercial software houses that try to rely on microsoft for software dev support (in my experience) end up sorely disappointed. Being able to contract out the support/bug fixing in a bid process can bring better prices. There's not reason that a third party couldn't provide adequate development support for an open source product.
The OP also seemed to be rolling all of support in the enterprise into the same support goal; like why waste money at all on vendor support for the dev workstations? That's ludicrous. You know they'll eventually need an IT person to maintain their windows workstations, even if microsoft is providing security patches. That person can do desktop support, and if they are competent, likely get better results faster than a commercial support vendor.
It sounds to me that the problem for this startup was more an issue of lack of leadership at the executive level with strong personal experience in open source embedded development. From the pricing, I'm pretty sure I know which RT linux vendor they went with, and if so, "reputable" was likely not evaluated from a developer standpoint. I would probably say that the "not want to spend time for any OSS bug fixing" attitude is the problem. I'd rather a platform with *all* the code PLUS noncommercial support any day over code+commercial support, or (worse) just the support. It's making a big assumption that somehow the commercial product is going to come bug free and that support is going to snap a patch out to you by the end of the week (or sooner).
I would say a shop running less than 10 devs is probably not going to get that level of attention from a commercial vendor, but who knows? Maybe they will. I'm sure that the OP will come back in six months and tell us all about how csharp, visual studio, and windows ce saved the day. ROI! TCO! Rah rah rah!
Yes, but is the Savage-Rabbit a hare-splitting idiot??
*duck*
*run*
(OUCH... *trip&fall*)
Yep. I was actually paid by my last employer for a couple of weeks to debug & plug memory leaks in poppler that I found profiling it in valgrind. I found two, one that was really bad, and one that wasn't so bad. It's really tough to do because PDF's are so damned complex. While there are many levels of indirection in the poppler/xpdf rendering code, it seems to be decently written, with a few exceptions. Memory is allocated in both the C++ and C way, and metadata specifying the method by which a chunk of memory is allocated is maintained with the allocated chunk. This is abstracted out so that there is (often) a single "smart" free() type of call that chooses the correct way to release/handle the memory (free or delete, realloc, etc).
To make things worse, there is a relatively sophisticated (to me!) caching subsystem that tricks valgrind into some false positives on leakage, so those had to be identified from the memory run traces. It was a mess.
Anyway, lots instantiations are flying around, so you end up matching pointer allocation/freeing and it's tedious. Unfortunately my company got cut in half before I finished, and I ended up in the half that needed new employment. I had just started playing with the memory debugging defines that are in the code, but they didn't seem to be terribly helpful for the particular leaks that I identified.
I'll probably go back some day and try to track down & finish my work, on my own time, but I'm not in any big hurry because debugging gui-library memory interactions for subtle memory leaks is not exactly the most fun open source side project. I personally can only do that for perhaps 2-3 hours at a time before my brain wants to completely shut down, or leave my head and drink scotch (or both).
I sincerely hope that I'm not the only with half-hearted interest in actually fixing memory utilization in that lib... that would be depressing. The project maintainer looks overworked and seems to be focusing on fixing crasholas and rendering bugs. At that rate, I seriously doubt he'll *ever* get to memory leaks.