If you use a garbage collector, you're deciding that it's worth a small performance penalty and a memory footprint that's slightly higher than optimal, and in exchange having vastly fewer memory leaks than is otherwise likely.
Well, sometimes not that small. You have to keep in mind that collection is far from free. At a conference I attended recently, there was a talk on avoiding garbage collection strain with certain applications using array slicing -- which basically works out to pointer aliasing, with the caveat that the alias can fall anywhere in the range allocated to the original pointer.
Still, I'd rather work with a garbage collector than without. I can be clever and use those techniques to reduce the work that the collector has to do, but if I screw up -- and no matter how good I am, I will; and when I do, it's going to be damned hard to find -- the garbage collector will take care of that.
For you, try a garbage collector that records a stacktrace for each allocation, and when it collects, log how much memory was allocated and where. Much faster and easier than hunting down memory leaks manually.
And when everyone finds themselves writing a lot of new/delete statements, it's about time they start using a language that has smart pointers as the default option (or at least as an option that's just as easy as regular pointers).
Well, that's one thing that Java did and got right, as much as it pains me to praise the language.
Of course, if you're allergic to garbage collection by default, you could have a garbage collector that you link in during debug mode that records everything it collects, along with a stack trace showing where it was allocated. That will show you very quickly where your memory leaks are.
There are valid reasons to want to avoid garbage collection. Mainly that it's an action that takes place at uncontrolled intervals and takes an unbounded amount of time to complete.
The faster development time with C# is orthogonal to its running in a virtual machine. There are languages around that offer the best of both worlds -- I currently use the D programming language for this.
Granted, the gtk and wx bindings are simple interfaces to the C version of the library, but higher-level abstractions can be written on top of those.
Google's interest mainly lies in being able to parse, represent, and produce files in the standard format, I think, regardless of who controls that format. They can certainly parse either format to get the majority of the textual content. It would be difficult to represent content in OOXML, but not ODF; and it is apparently significantly easier to modify ODF documents than OOXML, so I assume generating them is likely easier, too.
That's sufficient reason for Google to back ODF. Of course, the fact that it detracts from one of their competitors helps.
I think it's more popular to put your iPod on Linux than to put Linux on your iPod.
Additionally, there may be valid reasons for encrypting your firmware -- such as part of it being licensed proprietary stuff. But this move clearly removes Apple's competition from a market that it has no intention of entering. It's behavior that hurts their customers and hurts them and benefits no one.
Modal interfaces are usually harder to learn than non-modal ones, I think. Unless the changes between them are significant -- for instance, playing a first-person shooter and then pressing the escape key to get into a menu. That's the common argument against vim (though in vim, you can just press 'i' when you start and view all commands as starting with escape and ending with 'i' or enter).
I haven't used MSOffice 2007 much, but the thing that strikes me about its modal interface is that it is not obvious what changes between modes. In vim, you have to press a key to change modes, and that keypress usually has at most one side effect. (Not to mention that vim is aimed at expert and intermediate users, not novices.)
On the other hand, people will invariably forget to turn their phones off. Even if all phones turned off easily and didn't access the network, you'd get that interference.
It seems a bit petty: you're considered dangerous enough that the police secretly put a GPS transmitter in your car, you remove it ("hey, what's this? I don't recognize it"), sell it ("oh, Fred down the way might know what to do with it")...and suddenly you're being arrested for selling an object that, as far as you know, was legal to sell. As far as you could possibly know. Because you were being tracked in connection with some other, significant crime.
Even if you were charged, it'd be hard to get a jury to agree that you're at fault.
We're doing things in a reasonable amount of time these days that previously were possible only in an unreasonable amount of time, as far as 3D modeling and such.
I've heard that, in the early days of UNIX, computer time was expensive, so you could be wrong as long as you were fast. But these days, processor time is cheap, so you no longer have to be fast. Some people transfer this into automated verifications -- array bounds checking, for instance, or design-by-contract. Bounds checking is expensive for C/C++ primitive arrays, and not yet practical, but it's used efficiently in other languages.
I really think that good design practices interfere with efficiency in many cases. And I'm happy with that situation. I prefer stability to speed, but we're getting both, to some degree.
A command-line registry editor? You don't mean using vim to write a C# program that edits the registry, then invoking csc on that file, then running the output? Where is it? And how does it handle the evil practice of using GUIDs as registry directories?
If, for instance, the registry were an actual directory, containing subdirectories for each nonterminal registry directory and files for each terminal registry directory, a text editor and tab completion in a sane shell could get you 95% of the way there. And pretty much nothing will get you the rest of the way, since registry keys have a default value, so you don't need to have the key present in order for the program to work.
These are the two ways in which GNOME's gconf is better than the Windows registry. The typical UNIX example of rc files only solves one of the issues -- there are unspoken defaults -- but comments can help with that. And of course the gconf xml files don't have comments, since they aren't intended to be edited manually.
On the other hand, when I went from public school to home school, I completed three grades in a year. I couldn't *logistically* accomplish that while attending the public school, given a grade system; I would have needed a private tutor, or a small class of maybe five or ten people that was taught as a study group. So regardless as to whether the instructors were willing, I couldn't have gone significantly faster than the other students.
If you have a broader range of interests than most students, you can probably use that to avoid boredom: instead of trying to leap a year ahead in half the time, you can study twice as many things and keep pace with the class. I didn't.
Of course, in the US the situation is worse than in other countries; the No Child Left Behind act encourages schools to cater to the worst students and let the best fend for themselves.
Then don't allow them to compile schedulers as modules -- force each kernel to have a single scheduler built in. Then it's a matter of specifying the interface and then linking in a different object file.
It's doable (easy, even), it doesn't require significant investment from a kernel maintenance perspective, and it cuts through a fair bit of politicking.
The main complaints I have with Visual Studio is it's bloated and the debug inspector has a horrible interface. A bunch of narrow boxes that you have to hover over with your mouse. If I could set breakpoints as currently done and have inspection done like gdb, I'd be happy.
Species tend to last three million years or so. We aren't likely to face some global extinction in that span. So why talk about saving the human race by going off-planet? It'd be saving the race that the race that the race that the race that the race that the race that the human race becomes becomes becomes becomes becomes becomes. Further than that, probably, assuming we can get a good asteroid/comet defense system in place.
In the short term (fifty years or so), the most likely cause of our demise is ourselves, right? Nuclear winter and all? Nope; that'll drop the temperature by 22 degrees in temperate areas, 10 degrees in more tropical areas, for the first few months; but within a year the temperature will only be a few degrees off. Billions dead, but billions would survive.
And that's probably the best threat we have, unless some madman decides to build a rocket that can go to the asteroid belt and lob a few big rocks at us. Though that's unlikely to be anywhere near accurate enough to be a significant threat, even if such a rocket could be built.
"Free" assures that your expenses will be not only high, but never predictable. If something stops working... how do you know how much it will cost to fix it? The high priced consultants may figure it out quickly, or maybe it will take a few weeks of billable hours (or both- you may be paying for your consultants to read the newspaper... I've seen it happen). "Free" assures that you can never call the company to come and support (generally for free) the application they created. How is this any different from commercial applications? Microsoft hasn't offered free support for Windows recently, and if you submit a bug report, what are the odds that the issue will be resolved within the next year?
For a reasonably large company, using Microsoft software and finding a show-stopping bug means that you have to switch to another software vendor, but using FLOSS means that they can fix that bug. Using popular software means that you're far less likely to find a show-stopping bug, and being a small company means that fixing bugs in your platform rather than working on your product takes a larger portion of your efforts, more likely larger than it's worth.
But popularity is independent of the proprietary/free distinction in theory. In practice, it's due to other factors that there is a positive correlation in many areas.
So, currently it may be better for businesses to use proprietary software in many areas. But that needs to be evaluated on a case-by-case basis.
Excel understands HTML tables. IE6 runs under Wine, as does IE7's rendering engine -- though I doubt that does anything about the warning dialogs. However, if you're already running a virtual machine, running it under Linux is a minor change.
You could switch from OOo Writer to LaTeX. That way, your documents would look the same on every OS. Not practical, of course, if others need to edit your documents.
So, if anything, the GPLv3 frustrates the deals and MS would likely only be obligated to what was around when the deals were made. Right. In other words, Microsoft is only obligated to distribute GPL version 2 software. That depends on whether the MS-Novell deal specifies whether it applies to arbitrary software in SuSE or to specific software, and whether Microsoft can choose what parts of SuSE it distributes.
I imagine, though, if SuSE wants to renew the deal, or increase its scope, it will maintain a GPLv3-free branch for Microsoft to distribute. Unless the doctrine of first sale or some other law intervenes, given that Microsoft bought each license they distribute. (You wouldn't expect Borders to be bound by the GPL since they distribute Red Hat binaries with some Linux books, would you?)
This works only without arbitrage -- if everyone can get the product from anywhere it's sold, perhaps you'll simply have to deal with some people not buying.
With TrueCrypt, it's common practice to go two levels deep. Go at least three, preferably four. That way, you can even stand up to a bit of rubber hose cryptography.
Slashdot Mirror
More so then than if the original company released a Linux driver themselves.
If you use a garbage collector, you're deciding that it's worth a small performance penalty and a memory footprint that's slightly higher than optimal, and in exchange having vastly fewer memory leaks than is otherwise likely.
Well, sometimes not that small. You have to keep in mind that collection is far from free. At a conference I attended recently, there was a talk on avoiding garbage collection strain with certain applications using array slicing -- which basically works out to pointer aliasing, with the caveat that the alias can fall anywhere in the range allocated to the original pointer.
Still, I'd rather work with a garbage collector than without. I can be clever and use those techniques to reduce the work that the collector has to do, but if I screw up -- and no matter how good I am, I will; and when I do, it's going to be damned hard to find -- the garbage collector will take care of that.
For you, try a garbage collector that records a stacktrace for each allocation, and when it collects, log how much memory was allocated and where. Much faster and easier than hunting down memory leaks manually.
And when everyone finds themselves writing a lot of new/delete statements, it's about time they start using a language that has smart pointers as the default option (or at least as an option that's just as easy as regular pointers).
Well, that's one thing that Java did and got right, as much as it pains me to praise the language.
Of course, if you're allergic to garbage collection by default, you could have a garbage collector that you link in during debug mode that records everything it collects, along with a stack trace showing where it was allocated. That will show you very quickly where your memory leaks are.
There are valid reasons to want to avoid garbage collection. Mainly that it's an action that takes place at uncontrolled intervals and takes an unbounded amount of time to complete.
They say that about New York, and just about everywhere south of Anchorage but Seattle (if you don't like the weather in Seattle, just kill yourself).
The faster development time with C# is orthogonal to its running in a virtual machine. There are languages around that offer the best of both worlds -- I currently use the D programming language for this.
Granted, the gtk and wx bindings are simple interfaces to the C version of the library, but higher-level abstractions can be written on top of those.
Google's interest mainly lies in being able to parse, represent, and produce files in the standard format, I think, regardless of who controls that format. They can certainly parse either format to get the majority of the textual content. It would be difficult to represent content in OOXML, but not ODF; and it is apparently significantly easier to modify ODF documents than OOXML, so I assume generating them is likely easier, too.
That's sufficient reason for Google to back ODF. Of course, the fact that it detracts from one of their competitors helps.
$ wtf is ftw
ftw: ftw (3) - file tree walk
I think it's more popular to put your iPod on Linux than to put Linux on your iPod.
Additionally, there may be valid reasons for encrypting your firmware -- such as part of it being licensed proprietary stuff. But this move clearly removes Apple's competition from a market that it has no intention of entering. It's behavior that hurts their customers and hurts them and benefits no one.
Modal interfaces are usually harder to learn than non-modal ones, I think. Unless the changes between them are significant -- for instance, playing a first-person shooter and then pressing the escape key to get into a menu. That's the common argument against vim (though in vim, you can just press 'i' when you start and view all commands as starting with escape and ending with 'i' or enter).
I haven't used MSOffice 2007 much, but the thing that strikes me about its modal interface is that it is not obvious what changes between modes. In vim, you have to press a key to change modes, and that keypress usually has at most one side effect. (Not to mention that vim is aimed at expert and intermediate users, not novices.)
On the other hand, people will invariably forget to turn their phones off. Even if all phones turned off easily and didn't access the network, you'd get that interference.
EM shielding is a much more reliable solution.
It seems a bit petty: you're considered dangerous enough that the police secretly put a GPS transmitter in your car, you remove it ("hey, what's this? I don't recognize it"), sell it ("oh, Fred down the way might know what to do with it")...and suddenly you're being arrested for selling an object that, as far as you know, was legal to sell. As far as you could possibly know. Because you were being tracked in connection with some other, significant crime.
Even if you were charged, it'd be hard to get a jury to agree that you're at fault.
We're doing things in a reasonable amount of time these days that previously were possible only in an unreasonable amount of time, as far as 3D modeling and such.
I've heard that, in the early days of UNIX, computer time was expensive, so you could be wrong as long as you were fast. But these days, processor time is cheap, so you no longer have to be fast. Some people transfer this into automated verifications -- array bounds checking, for instance, or design-by-contract. Bounds checking is expensive for C/C++ primitive arrays, and not yet practical, but it's used efficiently in other languages.
I really think that good design practices interfere with efficiency in many cases. And I'm happy with that situation. I prefer stability to speed, but we're getting both, to some degree.
A command-line registry editor? You don't mean using vim to write a C# program that edits the registry, then invoking csc on that file, then running the output? Where is it? And how does it handle the evil practice of using GUIDs as registry directories?
If, for instance, the registry were an actual directory, containing subdirectories for each nonterminal registry directory and files for each terminal registry directory, a text editor and tab completion in a sane shell could get you 95% of the way there. And pretty much nothing will get you the rest of the way, since registry keys have a default value, so you don't need to have the key present in order for the program to work.
These are the two ways in which GNOME's gconf is better than the Windows registry. The typical UNIX example of rc files only solves one of the issues -- there are unspoken defaults -- but comments can help with that. And of course the gconf xml files don't have comments, since they aren't intended to be edited manually.
On the other hand, when I went from public school to home school, I completed three grades in a year. I couldn't *logistically* accomplish that while attending the public school, given a grade system; I would have needed a private tutor, or a small class of maybe five or ten people that was taught as a study group. So regardless as to whether the instructors were willing, I couldn't have gone significantly faster than the other students.
If you have a broader range of interests than most students, you can probably use that to avoid boredom: instead of trying to leap a year ahead in half the time, you can study twice as many things and keep pace with the class. I didn't.
Of course, in the US the situation is worse than in other countries; the No Child Left Behind act encourages schools to cater to the worst students and let the best fend for themselves.
Then don't allow them to compile schedulers as modules -- force each kernel to have a single scheduler built in. Then it's a matter of specifying the interface and then linking in a different object file.
It's doable (easy, even), it doesn't require significant investment from a kernel maintenance perspective, and it cuts through a fair bit of politicking.
VS + Resharper is pleasure.
The main complaints I have with Visual Studio is it's bloated and the debug inspector has a horrible interface. A bunch of narrow boxes that you have to hover over with your mouse. If I could set breakpoints as currently done and have inspection done like gdb, I'd be happy.
Species tend to last three million years or so. We aren't likely to face some global extinction in that span. So why talk about saving the human race by going off-planet? It'd be saving the race that the race that the race that the race that the race that the race that the human race becomes becomes becomes becomes becomes becomes. Further than that, probably, assuming we can get a good asteroid/comet defense system in place.
In the short term (fifty years or so), the most likely cause of our demise is ourselves, right? Nuclear winter and all? Nope; that'll drop the temperature by 22 degrees in temperate areas, 10 degrees in more tropical areas, for the first few months; but within a year the temperature will only be a few degrees off. Billions dead, but billions would survive.
And that's probably the best threat we have, unless some madman decides to build a rocket that can go to the asteroid belt and lob a few big rocks at us. Though that's unlikely to be anywhere near accurate enough to be a significant threat, even if such a rocket could be built.
Linux is a kernel, not a business. And, it being a kernel, you should not anthropomorphize it.
Hey, be fair. MS Office is second-rate.
For a reasonably large company, using Microsoft software and finding a show-stopping bug means that you have to switch to another software vendor, but using FLOSS means that they can fix that bug. Using popular software means that you're far less likely to find a show-stopping bug, and being a small company means that fixing bugs in your platform rather than working on your product takes a larger portion of your efforts, more likely larger than it's worth.
But popularity is independent of the proprietary/free distinction in theory. In practice, it's due to other factors that there is a positive correlation in many areas.
So, currently it may be better for businesses to use proprietary software in many areas. But that needs to be evaluated on a case-by-case basis.
Excel understands HTML tables. IE6 runs under Wine, as does IE7's rendering engine -- though I doubt that does anything about the warning dialogs. However, if you're already running a virtual machine, running it under Linux is a minor change.
You could switch from OOo Writer to LaTeX. That way, your documents would look the same on every OS. Not practical, of course, if others need to edit your documents.
I imagine, though, if SuSE wants to renew the deal, or increase its scope, it will maintain a GPLv3-free branch for Microsoft to distribute. Unless the doctrine of first sale or some other law intervenes, given that Microsoft bought each license they distribute. (You wouldn't expect Borders to be bound by the GPL since they distribute Red Hat binaries with some Linux books, would you?)
This works only without arbitrage -- if everyone can get the product from anywhere it's sold, perhaps you'll simply have to deal with some people not buying.
With TrueCrypt, it's common practice to go two levels deep. Go at least three, preferably four. That way, you can even stand up to a bit of rubber hose cryptography.