It's only bloated if you have a problem with sacrificing ~100 MB of hard drive space.
That's not the only issue. Bloated programs use more system memory. Loading a huge program will often knock good chunks of your other running tasks into swap memory, or at the very least flush out part of your cached I/O buffers. This can cause a significant hit to your overall system responsiveness, especially on machines without boatloads of physical RAM.
Of course any advantages that a staticly typed language provides in the way of helping editor gizmos are totally nullified by the huge increase in complexity of the APIs you have to deal with due to the static typing itself.
Just compare the Java libraries to the (often richer) Python libraries. Most Python API docs fit one or a couple of brief pages. Java gives you a thick a jungle of frames and trees to navigate for every stupid little call you have to make.
That's only because Microsoft dropped the original vision of MSN, which was a closed centrally controlled service like a glorified BBS. When it was introduced, they planned to leverage their desktop dominance to get the entire world to subscribe to their proprietary network.
The original MSN user interface that was bundled with Windows 95 looked more like the Windows file manager than a browser. I imagine that if MSN had continued down that path, then searching for information would today look more like some versions of the MSDN library help browser (based on a manually controlled central index) than like Google.
As it turned out, people preferred the freedom offered by the real Internet, and their plans never panned out.
regular expressions are nice and all but i still cant get used to them
They may be kind of hard to get used to, but not has hard as writing, debugging and maintaining a dozen or more lines of custom string parsing code for each case where you would use one.
The AMD numbers are also useful because they cover more of the factors that affect performance. AMD often sells CPUs with the exact same clock speed but different XXXX+ numbers. The performance difference in that case is due to different cache sizes or CPU architecture generations, but you can get a rough guess for their relative performance just by glancing at the model number. You don't need to be familiar with the details of their entire product line just to get a feel for what each chip will do.
Well, if it wasn't, it wasn't very hygienic because I don't remember them changing anything between shots.
I seem to remember getting TB vaccination at school with a funny multiple prick thing, but I think that the nurse used her thumb or a similar motion to jamb it into my arm. That hurt.
I remember lining up with my whole grade school class to get vaccinated for something-or-other with a needle-free gun. It only took a couple of minutes to do the whole class, and I didn't feel much of anything. This was circa 1973.
In the FUTURE, single core processors will be dual core processors where one side didn't pass quality control.
I kind of doubt it since the majority of the die real estate is occupied by cache memory, which is most likely shared between the two cores. So most defects wouldn't be fixable by just disabling one core.
If the installation is insecure, it's no skin off the AP manufacturer's back. The user is usually clueless about any breakins, and things "just work". If the user does figure out that he's been harmed, the vendor can easily deflect any blame: "You should have RTFM before you turned it on."
Effective security defaults would likely be more complex, which would involve more problems for user setup, which would generate more support calls. A million things could go wrong with a scheme like redirecting web connections to a password page, any one of which could generate a support call that erases all of the profits for that sale.
Thus, the AP vendors have no incentive to improve security, and in fact they have a financial incentive to not provide anything more than a superficial checkbox feature on the packaging. (This could change somewhat if a user ever successfully sues a vendor for losses caused by the lack of default security.)
Windows 95 or 3.11 doesn't suddenly lose features when they become 5 years old.
Well, Windows 3.11 may not lose any features, but it only had one useful feature to begin with: the ability to zap out into DOS mode to get some real work done.
However, in engineering, "unstable" often means "buggy", "defective" or "dangerous". That's what comes to mind when people hear that word; they don't refer to their dictionaries to look up less menacing definitions. The term "testing" isn't much better either.
The Debian project should really change their terminology if they don't want to scare people away unnecessarily. Any marketroid would tell them that it would be better to go with something like "Enterprise Edition", "Personal Edition" and "Exxtreme! Edition".
I would point out that whatever synchronization problems you think you have are absolutely nothing compared to what digital hardware designers contend with. The equations for their transistors are always "executed" in parallel, often to the tune of multiple independent clocks. The difference is that they are professionals that actually bother to use the proper tools for the job, instead of tying on the C/C++ blindfold and then whining about how unfairly hard it all is.
Yes, I used to design hardware, and it's very parallel. It's also a much more constrained problem. I hope you're not proposing that people use hardware design languages to write software, because they were designed for a specialized problem domain and would suck as general-purpose languages. They feel clunky enough as it is when used for hardware design.
Once you've done both hardware and software, then you'll realize that there are no silver bullets that cover all of the issues, and that includes your high-priced specialized CAD tools.
Multi-threading comes with synchronization, semaphore, mutex, etc, once you know how to deal with them, it's easy.
I know how to deal with them. It may seem easy at first, but it's actually very hard. Your program can run for days before a thread synchronization bug surfaces and it finally deadlocks. And since it's timing dependent, you can't reproduce it.
In principle there are rules to follow to avoid deadlocks and race conditions, but since they need to be manually enforced, there's always potential for error. At least with memory access bugs the hardware often shows you a segfault; with synchronization problems you usually don't even get that.
I've learned over the years that preemptive multithreading should be used only as a last resort, and even then, it's best to put exactly one synchronization point in the entire app. Self-contained tasks should be dispatched from that point and deliver their results back with little or no interaction with the other threads.
The worst thing you can do is randomly sprinkle a bunch of semaphores, mutexes, etc. all over your app.
E.g., good luck finding someone who'll come over and take professional photos at your wedding, just for fame and recognition.
Wedding photos would work fine without copyright. You pay the photographer to take some pictures, you get your photos. None of this "Photographer owns pictures of your event that he was *hired* to make" bullshit.
Actually, the biggest reason for the Duke Nukem Forever delays was their decision to make the on-disk file formats dependent on upcoming WinFS features. The only reason they keep switching game engines is to keep the graphics up-to-date while they wait for Microsoft to finish the filesystem.
I'd be interested in hearing about the new technology since then as well as what they plan to do.
In the wake of the disastrous 1980 eruption, the government has been stockpiling hundreds of thousands of tons of baking soda in depots all along the Cascade Range.
The plan to combat future eruptions is to utilize a fleet of C-130 transports to bombard the volcanoes with massive quantities of baking soda. When the blanket of baking soda combines with the acidic volcanic gasses and melting snowcaps, it will expand into a thick layer of foam that will absorb any lava, ash or debris before it can cause problems for the areas below.
Our government was very careless in 1980 when they didn't do anything to stop the eruption. They've learned their lesson, and this time around they're not going to be caught off guard.
these companies sue the big guys, because the big guys have money.
Sometimes. Other times, they start off at the bottom and work their way up in order to establish a precedent of settlements to give their patent an aura of legitimacy. They know that the little guys are much more likely to capitulate or lose the case outright with their limited legal resources.
Moreover, it can make sense to make a few examples even if those cases don't make money by themselves. It will make it much more likely that other victims will cough up cash when they get a letter demanding a cut of the action.
I'd put odds on Apple not paying a cent for infringing this patent.
However, Apple will probably need to spend hudreds of kilobucks in legal fees to get rid of this problem. Luckily for Apple, they can afford it.
If it happened to a much smaller company, they might not have the resources necessary to overcome this stupid "patent" that some examiner let slide because he was "annoyed". That's a wonderful reason for the potential destruction of someones's livelyhood: invalid patents issued because some civil servant is in a bitchy mood one morning.
What might be the reason for this star burning when other similarly sized objects do not?
Once a gaseous object gets to be the size of Jupiter, adding more material to it causes its diameter to shrink because of the increasing mutual gravitation. As even more matter is added, the shrinking effect is eventually counteracted by thermal expansion caused by fusion once it ignites into a star. After that point, the diameter grows again as the fusion rate increases with more mass.
Apparently, this object has many times the mass of Jupiter, but not so much that that its diameter has rebounded past that of Jupiter.
Well, why not think outside of the box and have it run on OSX?
Preliminary testing with OSX found that the shiny translucent plastic ATM faceplates were far too susceptible to scratching and scuffing for use in the field.
I routinely get 99% utilization on two simultaneous processes per CPU with hyperthreading.
But are you really getting 198% of the work done in the same time? Most any OS-level CPU monitor wouldn't have any way to discriminate the micro wait states that the two threads pause in while they contend for cache and memory resources. To the OS, both threads would look 100% "busy" even if they were flushing so much of each others' data out of the cache that performance dropped below the single-threaded case.
Okay, so they are getting a product ready to do that, and working on getting other features that competitors have ramped up for future versions. It's called having a plan. You can't release a product that is on par with 5 or 10 year established competitors at the 1.0 level.
IOW, the announcement is FUD designed to flummox competitors and ward off customer defections while Microsoft figures out whether they actually need to do anything about this market segment. It's not a new strategy for them but it's usually been an effective one.
Slashdot Mirror
That's not the only issue. Bloated programs use more system memory. Loading a huge program will often knock good chunks of your other running tasks into swap memory, or at the very least flush out part of your cached I/O buffers. This can cause a significant hit to your overall system responsiveness, especially on machines without boatloads of physical RAM.
Just compare the Java libraries to the (often richer) Python libraries. Most Python API docs fit one or a couple of brief pages. Java gives you a thick a jungle of frames and trees to navigate for every stupid little call you have to make.
That's only because Microsoft dropped the original vision of MSN, which was a closed centrally controlled service like a glorified BBS. When it was introduced, they planned to leverage their desktop dominance to get the entire world to subscribe to their proprietary network.
The original MSN user interface that was bundled with Windows 95 looked more like the Windows file manager than a browser. I imagine that if MSN had continued down that path, then searching for information would today look more like some versions of the MSDN library help browser (based on a manually controlled central index) than like Google.
As it turned out, people preferred the freedom offered by the real Internet, and their plans never panned out.
They may be kind of hard to get used to, but not has hard as writing, debugging and maintaining a dozen or more lines of custom string parsing code for each case where you would use one.
The AMD numbers are also useful because they cover more of the factors that affect performance. AMD often sells CPUs with the exact same clock speed but different XXXX+ numbers. The performance difference in that case is due to different cache sizes or CPU architecture generations, but you can get a rough guess for their relative performance just by glancing at the model number. You don't need to be familiar with the details of their entire product line just to get a feel for what each chip will do.
Well, if it wasn't, it wasn't very hygienic because I don't remember them changing anything between shots.
I seem to remember getting TB vaccination at school with a funny multiple prick thing, but I think that the nurse used her thumb or a similar motion to jamb it into my arm. That hurt.
I remember lining up with my whole grade school class to get vaccinated for something-or-other with a needle-free gun. It only took a couple of minutes to do the whole class, and I didn't feel much of anything. This was circa 1973.
Maybe someone should ask to see a copy of his license.
I kind of doubt it since the majority of the die real estate is occupied by cache memory, which is most likely shared between the two cores. So most defects wouldn't be fixable by just disabling one core.
Effective security defaults would likely be more complex, which would involve more problems for user setup, which would generate more support calls. A million things could go wrong with a scheme like redirecting web connections to a password page, any one of which could generate a support call that erases all of the profits for that sale.
Thus, the AP vendors have no incentive to improve security, and in fact they have a financial incentive to not provide anything more than a superficial checkbox feature on the packaging. (This could change somewhat if a user ever successfully sues a vendor for losses caused by the lack of default security.)
Well, Windows 3.11 may not lose any features, but it only had one useful feature to begin with: the ability to zap out into DOS mode to get some real work done.
The Debian project should really change their terminology if they don't want to scare people away unnecessarily. Any marketroid would tell them that it would be better to go with something like "Enterprise Edition", "Personal Edition" and "Exxtreme! Edition".
I haven't been able to get anything other than:
Yes, I used to design hardware, and it's very parallel. It's also a much more constrained problem. I hope you're not proposing that people use hardware design languages to write software, because they were designed for a specialized problem domain and would suck as general-purpose languages. They feel clunky enough as it is when used for hardware design.
Once you've done both hardware and software, then you'll realize that there are no silver bullets that cover all of the issues, and that includes your high-priced specialized CAD tools.
I know how to deal with them. It may seem easy at first, but it's actually very hard. Your program can run for days before a thread synchronization bug surfaces and it finally deadlocks. And since it's timing dependent, you can't reproduce it.
In principle there are rules to follow to avoid deadlocks and race conditions, but since they need to be manually enforced, there's always potential for error. At least with memory access bugs the hardware often shows you a segfault; with synchronization problems you usually don't even get that.
I've learned over the years that preemptive multithreading should be used only as a last resort, and even then, it's best to put exactly one synchronization point in the entire app. Self-contained tasks should be dispatched from that point and deliver their results back with little or no interaction with the other threads.
The worst thing you can do is randomly sprinkle a bunch of semaphores, mutexes, etc. all over your app.
Wedding photos would work fine without copyright. You pay the photographer to take some pictures, you get your photos. None of this "Photographer owns pictures of your event that he was *hired* to make" bullshit.
Actually, the biggest reason for the Duke Nukem Forever delays was their decision to make the on-disk file formats dependent on upcoming WinFS features. The only reason they keep switching game engines is to keep the graphics up-to-date while they wait for Microsoft to finish the filesystem.
In the wake of the disastrous 1980 eruption, the government has been stockpiling hundreds of thousands of tons of baking soda in depots all along the Cascade Range.
The plan to combat future eruptions is to utilize a fleet of C-130 transports to bombard the volcanoes with massive quantities of baking soda. When the blanket of baking soda combines with the acidic volcanic gasses and melting snowcaps, it will expand into a thick layer of foam that will absorb any lava, ash or debris before it can cause problems for the areas below.
Our government was very careless in 1980 when they didn't do anything to stop the eruption. They've learned their lesson, and this time around they're not going to be caught off guard.
Sometimes. Other times, they start off at the bottom and work their way up in order to establish a precedent of settlements to give their patent an aura of legitimacy. They know that the little guys are much more likely to capitulate or lose the case outright with their limited legal resources.
Moreover, it can make sense to make a few examples even if those cases don't make money by themselves. It will make it much more likely that other victims will cough up cash when they get a letter demanding a cut of the action.
However, Apple will probably need to spend hudreds of kilobucks in legal fees to get rid of this problem. Luckily for Apple, they can afford it.
If it happened to a much smaller company, they might not have the resources necessary to overcome this stupid "patent" that some examiner let slide because he was "annoyed". That's a wonderful reason for the potential destruction of someones's livelyhood: invalid patents issued because some civil servant is in a bitchy mood one morning.
Once a gaseous object gets to be the size of Jupiter, adding more material to it causes its diameter to shrink because of the increasing mutual gravitation. As even more matter is added, the shrinking effect is eventually counteracted by thermal expansion caused by fusion once it ignites into a star. After that point, the diameter grows again as the fusion rate increases with more mass.
Apparently, this object has many times the mass of Jupiter, but not so much that that its diameter has rebounded past that of Jupiter.
Preliminary testing with OSX found that the shiny translucent plastic ATM faceplates were far too susceptible to scratching and scuffing for use in the field.
But are you really getting 198% of the work done in the same time? Most any OS-level CPU monitor wouldn't have any way to discriminate the micro wait states that the two threads pause in while they contend for cache and memory resources. To the OS, both threads would look 100% "busy" even if they were flushing so much of each others' data out of the cache that performance dropped below the single-threaded case.
IOW, the announcement is FUD designed to flummox competitors and ward off customer defections while Microsoft figures out whether they actually need to do anything about this market segment. It's not a new strategy for them but it's usually been an effective one.
Since the global flyer looks just like a glider with a jet engine bolted on, I wouldn't doubt it all that much.