"Focusing on IP" has nothing to do with being a fabless chip manufacturer. Transmeta never had a fab line they owned in the first place. ARM, for example, produces a fine line of embedded procesor products, but owns no fabrication facilities. Most chip makers are actually fabless, because so few companies have the massive capital and/or economies of scale required to build and maintain modern fabrication facilities. Everyone else just rents facility time from companies with fabs.
No, it only gets called DRM when MS triggers lockdowns of functionality when the signed driver check is disabled. Such as disabling playback of high-def protected content when unsigned drivers are loaded.
DRM or no, this measure stinks of a band-aid approach, and of typical CYA mentality: it's not about protecting the user's data, it's about protecting Microsoft's data (and business deals, etc.).
The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet.
Which is also why it's generally a lousy idea to allow DMZ hosts to initiate general connections into the intranet in the first place. Defense in depth -- even if the admin screws up and allows agent forwarding to DMZ hosts, an attacker won't immediately be able to use those credentials to ssh from the DMZ into intranet hosts.
If you're in a place where security is sufficiently tight to have mechanisms to prevent this (ie: Security Guards) then they're likely to be sufficient to cover the little password notes in the top drawer as well as the machine itself.
But this doesn't protect against the greatest threat: insiders who can get right past the security guards. If an insider's up to something truly nefarious, better to use someone else's credentials to do it (especially if they have access priviliges you don't.)
Remember, the point of login credentials in most organizations isn't just to identify someone as part of the organization, but also to determine identity and levels of access to resources.
The PP chip does not require an external audio codec (what do you think those two ARMs are for?).
You're confusing terminology on this point. The parent was correctly referring to the external D/A converter chip, such as the Intel Aduio Codec '97 chips often found in PC Hardware (and which the PPI chips support) or an I2S chip such as Wolfson Microelectronics' or Sigmatel's offerings -- which are more suited to the portable embedded space than power-hungry AC'97 chips.
So the parent's claims are that the BOM (Bill of Materials) costs for competing solutions will be lower in part due to the lack of an integrated D/A solution. This may or may not actually be true today -- also note that Apple's cost per unit for the PPI chip isn't public knowledge (or was that released when I wasn't looking?). As of a few years back, the integrated solutions I was aware of had MP3-specific hardware not amenable to Apple's use (recall, Apple needs MP3, AAC, the PCM formats, Apple Lossless, etc.). I'll also note that it can be a major PITA to integrate analog electronics on the same silicon as your digital electronics. Not for the faint of heart or those without some good analog engineers.
Flash memory cells will indeed wear out after some number of writes.
Also note that modern hard drives have various layers of reliability engineered into their design. There's all sorts of bad data at the level of the signal hitting the drive head. That could be spot media failure, a transient failure (e.g. signal magnitude wasn't high enough on that pass) and so forth. Error correcting codes(ECC) and bad block detection and marking are examples of techniques used to achieve the desired levels of reliability. Without these approaches, the storage available on modern drives would be radically lower than it is, since we'd have to rely solely on media and mechanism integrity. That is, to get a net reliability of failures to an acceptable level, a battery of approaches are used beyond media integrity.
The same general concepts can be applied to a flash-based drive to improve reliability under the assumption that media failures will occur, but should be recoverable. In the case of flash, a write distribution mechanism would also be added to the techniques used to improve reliability.
Visual Studio is usually considered one of the best if not the best IDE for development
Who the hell says *that*? I'm stuck using Visual Studio daily for development, and I must say that it has more GUI and tool-level interface stupidity than I can shake a stick at. Just a sampling of peeves with the flaming pile that is Visual Studio:
Profiling anyone? At least there's something in the way of profiling in VS8. That's just embarrassing; the largest software company in the world can't manage to get in a feature that's practically standard in the embedded IDE world.
Tab ordering is heavily unpredictable and unnavigable. VS tries to do some sort of most-recent ordering thing, which becomes random ordering to the user once more than a small handful of files are open.
Editors vaguely try to obey the line-ending convention of a file, but in practice create mixed-ending files if the original used Unix line ending conventions. This is a critical failing, since it can hose diff/merge in source control tools (e.g. CVS, or others that aren't explicitly line-ending aware).
The organization of panes changes for debug mode, but includes a lot of useless shuffling. Oh, look, the Solution Explorer decided it needed to still be present, but on the left as opposed to the right side of the display. WTF?
Discovery of keybindings SUCKS! Buttons bound to keys don't always (or ever?) show the bindings.
The UI for editing keybindings is also excremential. Not the least of its problems is Mystery Meat syndrome for the bound operations. The user has to pretty much guess and/or trial and error to figure out which of the likely named bindings, if any, does the right thing. (apropos-search in Emacs, anyone?)
If you really think VS is all that good, then you owe it to yourself to go use Eclipse for awhile. It shares some good concepts also seen in Visual Studio, and does just about everything else better from a UI perspective.
Note that foam generally does a pretty good job of absorbing sound reflection, but what many folks don't understand is that it's fairly poor at dealing with sound transmission. It helps a lot that computer noise tends to be relatively high frequency, which foam is better at absorbing. As an example, an attempt to dampen out upstairs neighbors' footsteps using acoustic foam is an expensive way to do nothing. Especially as all acoustic foam is less effective the lower the frequency of the sound.
In TFA, the foam primarily seems to be used to dampen internal reflections, making the case's sound reduction more effective. E.g. foaming the inside of the venting duct helps to reduce high frequency noise escaping from the duct. Clever.
A great solution that I've used over the years is to just shove the computer into a closet, or even into the basement if the space affords it. When scouting out new living spaces, the ability to keep computers out of earshot has often been a key decision maker for me. I even got my last landlord to let me put a 4" circular port for cable passage into a closet off of a finished basement for just such purposes. Air space in the port was filled with foam discs cut to size -- open air passage between the computers and your space is to be avoided. Worked great; computers in the closet were completely inaudible more than a foot from the cable port.
Once again, I like Bruce Schneier's proposed solution:
The bank must be made responsible, regardless of what the user does.
That quote is from Mitigating identity theft, which provides a refreshing perspective on the problems collectively labelled as identity theft. Bruce points out that many of the "solutions" to identity theft focus on authentication, which misses a critical part of the equation: the fradulent transaction itself. By providing a strong financial incentive to banks to mitigate fraud, the only party which has a real chance to do anything about the problem will fix it and fast.
As others have pointed out, the proposed position is a PR position. I want the real deal -- actual security not the appearance of it. On that note, the clueless keep making noise about Unix being "fundamentally more secure" than Windows, and that's bullshit. Let's be clear: the practical differences between OS X and WinXP in terms of security come down to the vendor's practices and the dilligence of the admins. There's no technological magic juice here. There are, IMO, zero fundamental differences between OS X and WinXP (or stock Linux) when it comes to the potential for local or remote vulnerabilities. Local and remote exploits are quite possible and practical on all these platforms.
Thus Apple has two approaches it can take. First, it can consider tactics that harden the system as a whole, making it much harder for exploits to work in the first place. Look to approaches such as those taken by grsecurity, SELinux, and the other layers found in hardened Linux and *BSD distros for examples. Harden the hell out of the kernel and compiler layers as baseline approach. Perhaps fund Coyotos work as a strategic-term approach, with an eye towards migrating the kernel. The room for innovation here is to present a hardened system that isn't any harder to use.
Second, Apple simply must be dilligent in identifying and fixing exploits. To that end, I'd propose that Apple offer a substantial first-reporter bounty for local and remote exploits on the Mac OS X platform. Think about it: set aside the equivalent salary+overhead of one or more good security experts. Divvy that amount out to leverage a larger community each year. I'd love to see a few students help pay their way through college this way. 8-)
Forget the illusion of no exploits -- go out, find 'em, and close 'em first.
I guess you could say that the reliability of software is like a wave: It goes up until a major release, then it drops down to the bottom and starts working it's way back up again.
The software company *I* work for actually manages to release damn good software for every stable release, even in the presence of major feature additions or changes. We do patch releases, but very few and largely for minor issues. Nor do we have a very long development cycle time. That "wave", while present, is barely big enough to lap at your toes.
Perhaps it's time to take a long hard look at your software development process? Or look elsewhere for a smarter dev culture?
[...] for a developers interested in using Rails, updating Ruby is fairly trivial.
Another point is that many people use a custom install of Ruby to ensure that they're using the same version as their webhosting service. There's no reason to run a newer version when that just introduces an unecessary difference between your development and production environments.
Right. Like anyone in America gives a fuck about their rights and how they are losing them.
That's why an informed electorate is the lifeblood of democracy. More Americans might care, if they even had a clue what was going on or what was at stake. On just one area: How many people, left to their own devices, have the time, energy, and wherewithal to figure out the differences between trademarks vs. patents vs. copyright vs. trade secrets vs. the fiction of "intellectual property"? How many would then make the leap to form opinions and understand the changes that our government has made the last decade on issues such as the public domain, fair use, reverse engineering, patent proliferation, and so on? And after that successfully influence public policy on any matter?
If left to do their own footwork, precious few would make it past even the earliest hurdles. In and old and romantic theory, journalists serve as the advocates for the people, identifying and reporting on issues that impact the people and the public domain. There are some that still do this work, but the conflicts of interest in news media are staggering. More than distortion in news that's written, there's the story of what news stories are told and (more importantly) what aren't.
Now expand the problem from the limited scope of information rights issues to the vast panoply of domestic and international public policy issues... it's downright overwhelming. Especially considering that the few who truly get informed and become activists must combat the power of monied special interest lobbies.
It's certainly possible and worthwhile to become an informed citizen, but it takes work, and the skill to discriminate between poor and reliable news sources. Worse, going through this process challenges the comfortable platitudes dished out by the media and the major political parties. There's that choice of red pill vs. blue pill again -- stay within the comfortable zone of information control, or wake up and smell reality.
I don't get food stamps, a welfare check, my kids don't go to public schools (I don't have any), but I pay taxes that go into these programs.
The programs you cite are elements of a public welfare system available to all citizens equally based on need. The argument of the grandparent and other posters is that the CD-R tax unfairly impacts the taxed (e.g. anyone not copying music industry copyrighted content) given its stated motives. Further, the distribution of the tax's proceeds is discriminatory against large classes of the allegedly impacted (e.g. independent artists or other non-music industry content creators whose works are copied onto CD-R media).
So what? That's the story of every modern processor, because the true engineering problem is to create a synthesis of processor and compiler that produces a powerful platform. Put another way, modern general purpose processors aren't targeted at assembly programmers. Itanium, however, seems to have been plagued by outright hardware design and engineering issues above and beyond any hardware/compiler synthesis issues.
a) Hire engineers who know engineering and are crappy programmers, and make them learn programming
I disagree that this is preferable. It takes more than that same "4 years to teach them engineering" to get an untrained programmer writing code to the same standard of the hypothetical trained and experienced CS major.
This may be acceptable for some applications, esp. small, useful mathematical tools. The more sophisticated the project scope starts at (or grows to), the greater the benefit in having folks around who actually understand production software development. You really want your engineers able to focus on their engineering, and the software folks to focus on the software. Given that many engineers can code to some extent, a good developer can often write frameworks that allow the engineers to do some coding, concentrating on their problems without getting mired in aspects of software design that really aren't their specialty. In some sense, this very idea speaks directly to the success of tools popular in engineering and the sciences, such as MATLAB and Mathematica.
Steve wants to tell me what I can and can't play on an iPod (e.g., suing Real).
This is a problem with changes in legislation in the US (DMCA, etc.) that are restricting previously established reverse engineering rights for interoperability purposes. Rule: once a legal weapon is open to a corporation, they almost have to use it lest they get whalloped by the competition pulling the trigger first.
BUY an official copy of OS/X, then who the hell is Steve Jobs to tell me what I can or can't do with it?
You didn't buy a copy of OS X. Not in the same sense that you, for example, bought a frying pan or even a book. You bought a software license that comes to you under terms. As the license holder Apple can set those terms.
Note that I'm not saying that reverse engineering should be limited, or that I agree with the extension of copyright via nearly arbitrary EULA plus corporate legal power. However, being angry at Apple over these issues, or Amazon over the one-click patent, or AT&T over the XOR patent, and so on, is really a huge waste of time and energy. Consider that:
In the US, corporations are effectively legal super-beings. They have immunities not available to individual people and they have a concentration of financial power that provides incredible leverage against opponents through the legal system and other social means.
There are few powerful and effective motivations, legal or otherwise, for corporations to act in anything other than profit-driven self-interest.
Given 1 and 2, corporations are practically forced to leverage all available legal options at their disposal as a matter of survival. This includes lobbying state and federal legislatures to gain commercial advantage. Occasionally a corporation appears that in some way hews to an ethical or principled approach to the way they work, but that's the faint exception rather than the rule.
More to the point, the U.S. and other countries have established a legal environment (via laws and precedents) that resulted in the above conditions. So the question comes to mind: if you're going to direct your energy somewhere to fix these problems, is it better to rail away ineffectually at a corporation who won't hear your complaint anyway... or is it better to put that energy into altering the system that produced that corporation's behavior in the first place?
At least on Mac OS X, Firefox has some very specific problems that can contribute to this perception.
Bug 141710: Holding down mouse button forces 100% CPU on Macs is a real stinger. It it seems from discussion on this bug and a number of others that the real solution is to move Firefox on OS X off of Carbon and onto the Cocoa framework (Bug 111230: Use Cocoa for Widget instead of Carbon. That effort has an independent dev working on a port, but there seems to be little official impetus to make OS X into a first-class platform for Firefox. In response to the obvious cries of "go write code", I don't have the time and/or Cocoa knowledge to efficiently pitch in on this one. Or put another way, I don't have time to be a developer on every app that I use... %-/
I used to like Camino, and I might give it another whirl, but I've really gotten to like Firefox in many ways. I'm particularly hit by the lack of extensions or search plugins in Camino. In particular, the Web Developer Extension and Live HTTP Headers extension for FF are awesome if you have use for such things. The Sage RSS reader extension is also fairly nice.
Nice quip, but the realities of the situation are completely different. My take on EPIC nee IA-64 when it was first publicly announced was surprise at an architecture that actually encouraged ultra-complex processor control logic. This, when prevailing trends tended to find ways to manage or reduce that complexity, or at least provide unambiguous chip-compiler synergy. Put another way, Intel made design choices that made the hardware itself very challenging to build and properly synergize with a compiler to achieve high total performance. Intel had certainly shown their chops at this sort of high-complexity chip controller design in the x86 line, but the move still seemed brazen from an outsider's perspective. History now shows that they certainly had trouble going down that path...
Cell, however, is basically a bog-stock PowerPC with DSP engines at its disposal. Think Altivec/MMX/SSE type units on steroids. This approach provides computing power that isn't applicable to all tasks, but is generally proven to perform well for applications that require high performance mathematical processing. Incidentally, that's precisely the target market that IBM's stated they're after with Cell-based servers. Moreover, Cell's scalability model and hardware complexities are much more managable.
To really leverage Cell's power from the software side will require some or all of 1) good compiler and toolchain support, 2) good library support, and 3) dedicated development effort for the specific application. IBM has the expertise and motivation to provide 1 and 2, and developers in the supercomputing world tend to get really good at 3. When your *highly optimized* supercomputer app may take on the order of a year to run, big emphasis tends to be put on making it run fast. Months of work to save years of time.
It still remains to be seen how this effort will play out in the marketplace, but variants of Cell's basic approach are working right now in many, many devices.
Good link, but the references get successively weaker as they shift from the relationship of close work and myopia to the effectiveness of plus lenses in halting and/or reversing the progress of myopia. Esp. number 2 and 5, with phrases such as "This is common knowledge and is covered in all vision textbooks." and "This is self-evident since the ciliary muscle has no opportunity to relax." If something is common knowledge, then provide the early seminal reference on it. Really. And NOTHING is self-evident when it comes to biological systems. (In this context, there's a trivial example: what about sleep? Eye muscles don't relax during sleep?)
The data shown for 8 is appealing, but insufficient. Numbers for the three groups are given, but what ARE those numbers? Average, median, etc? What was the distribution, statistical significance of the changes, etc? Was the study large enough and properly conducted such that the findings were statistically valid? Yes, I can go dig up the original paper, but the reference itself wasn't presented with rigor.
#9 has *no* reference to statistically validated data. Just case studies. Case studies are interesting to get an idea about a phenomenon, but you can pick and choose case studies to show *anything* -- just see the other replies to this thread for examples of that.
Last but not least, the researcher cited in #9 is none other than the creator of the site and the founder of the International Myopia Prevention Association, per their about page: http://www.preventmyopia.org/aboutus.html
Note that none of this is damning, but it takes a lot more rigor (and some chutzpah) to push though a change in the established thinking than this organization seems to be putting forth from their "validation" page.
So the question becomes: is this for real? Or is it the pipe dream of one man who hasn't found a way to conclusively prove (or disprove) his claims?
Note that I'm not trying to cast aspersions on this organization or Dr. Rehm. I'm only pointing out that it is very important to very rigorously evaluate all the random claims that one comes across these days. Conversely, it is extremely challenging to rigorously present an as-yet unaccepted scientific position.
The parent is definately correct. This is cutting edge.. many doctors still refuse to acknowledge this.
There are times that any profession, physicians included, undergoes the throes of a Khunian revolution. Consider the recent Nobel awarded to the great researchers responsible for correctly characterizing peptic ulcers as a bacterial infection. They had to fight the established dogma that ulcers were stress-related and thereby mystic and incurable.
Both the old myths of ulcers and the new urban legend of eyeglasses causing poor eyesight lacked one big thing: rigorous scientific proof. Are there *any* well-conducted, statistically valid, peer-reviewed studies that show (e.g.) that glasses worsen myopia? That reading glasses prevent or reverse the progress of myopia in children? This keeps coming up as an urban legend, and if there's no science backing it, doctors are right to "refuse to acknowledge it" -- because it's a load of bollocks!
Etymotic, with their earphones that absolutely seal into your ear canal, blocking out almost all outside noise, and putting themselves very close indeed to your eardrum.
I've been using a pair of Etymotic ER-4S headphones for about five years now. In practice, I find Ety's are far safer than normal earbuds for just the reason you cite. Since the outer part of the earbud is essentially an earplug with excellent noise blocking, the headphone doesn't have to compete volume-wise with ambient noise. You get the same clarity of sound with a lower volume level due to this.
It's also worth noting that due to the Ety's proximity to the eardrum, they don't need to be very loud at all. Their drivers run intentionally quiet for this reason. For comparison, with conventional headphones or earbuds if I set them at a comfortable listening level then set them down on the desk, I find that I can still hear the sound to some extent. With Ety's, I can't even tell whether they're on unless the volume is particularly loud or it's *very* quiet in the room.
Of course, it's critical with any headphone, Ety's or otherwise, to train yourself to moderate playback volume for extended listening.
Slashdot Mirror
"Focusing on IP" has nothing to do with being a fabless chip manufacturer. Transmeta never had a fab line they owned in the first place. ARM, for example, produces a fine line of embedded procesor products, but owns no fabrication facilities. Most chip makers are actually fabless, because so few companies have the massive capital and/or economies of scale required to build and maintain modern fabrication facilities. Everyone else just rents facility time from companies with fabs.
No, it only gets called DRM when MS triggers lockdowns of functionality when the signed driver check is disabled. Such as disabling playback of high-def protected content when unsigned drivers are loaded.
DRM or no, this measure stinks of a band-aid approach, and of typical CYA mentality: it's not about protecting the user's data, it's about protecting Microsoft's data (and business deals, etc.).
> Show fud and !notfud to door
;-)
Impressed with your obvious genius at having both fud and !notfud, the door opens.
(With apologies to everyone who's ever played the HHGTTG infocom game...
The DMZ hosts aren't supposed to be safe, that's why they're in the DMZ and not in the intranet.
Which is also why it's generally a lousy idea to allow DMZ hosts to initiate general connections into the intranet in the first place. Defense in depth -- even if the admin screws up and allows agent forwarding to DMZ hosts, an attacker won't immediately be able to use those credentials to ssh from the DMZ into intranet hosts.
If you're in a place where security is sufficiently tight to have mechanisms to prevent this (ie: Security Guards) then they're likely to be sufficient to cover the little password notes in the top drawer as well as the machine itself.
But this doesn't protect against the greatest threat: insiders who can get right past the security guards. If an insider's up to something truly nefarious, better to use someone else's credentials to do it (especially if they have access priviliges you don't.)
Remember, the point of login credentials in most organizations isn't just to identify someone as part of the organization, but also to determine identity and levels of access to resources.
The PP chip does not require an external audio codec (what do you think those two ARMs are for?).
;-)
You're confusing terminology on this point. The parent was correctly referring to the external D/A converter chip, such as the Intel Aduio Codec '97 chips often found in PC Hardware (and which the PPI chips support) or an I2S chip such as Wolfson Microelectronics' or Sigmatel's offerings -- which are more suited to the portable embedded space than power-hungry AC'97 chips.
So the parent's claims are that the BOM (Bill of Materials) costs for competing solutions will be lower in part due to the lack of an integrated D/A solution. This may or may not actually be true today -- also note that Apple's cost per unit for the PPI chip isn't public knowledge (or was that released when I wasn't looking?). As of a few years back, the integrated solutions I was aware of had MP3-specific hardware not amenable to Apple's use (recall, Apple needs MP3, AAC, the PCM formats, Apple Lossless, etc.). I'll also note that it can be a major PITA to integrate analog electronics on the same silicon as your digital electronics. Not for the faint of heart or those without some good analog engineers.
Disclaimer: I used to work for PortalPlayer.
Some of the tabbing issues being addressed are actually big fat bugs, such as what happens when you open too many tabs in one window (which I do all the time... :-P ). E.g. see Bug 221684: When opening too many tabs you can't move to them with the mouse ("X" button and tabs overlap) for a prime example. This case simply wasn't handled at all gracefully in the GUI -- tabs just "run off" of the right side.
Tho I am curious to play with the alpha to see what other changes might be in store. Who knows, maybe I'll get to go do some damage in Bugzilla? 8-)
Flash memory cells will indeed wear out after some number of writes.
Also note that modern hard drives have various layers of reliability engineered into their design. There's all sorts of bad data at the level of the signal hitting the drive head. That could be spot media failure, a transient failure (e.g. signal magnitude wasn't high enough on that pass) and so forth. Error correcting codes(ECC) and bad block detection and marking are examples of techniques used to achieve the desired levels of reliability. Without these approaches, the storage available on modern drives would be radically lower than it is, since we'd have to rely solely on media and mechanism integrity. That is, to get a net reliability of failures to an acceptable level, a battery of approaches are used beyond media integrity.
The same general concepts can be applied to a flash-based drive to improve reliability under the assumption that media failures will occur, but should be recoverable. In the case of flash, a write distribution mechanism would also be added to the techniques used to improve reliability.
Who the hell says *that*? I'm stuck using Visual Studio daily for development, and I must say that it has more GUI and tool-level interface stupidity than I can shake a stick at. Just a sampling of peeves with the flaming pile that is Visual Studio:
If you really think VS is all that good, then you owe it to yourself to go use Eclipse for awhile. It shares some good concepts also seen in Visual Studio, and does just about everything else better from a UI perspective.
Note that foam generally does a pretty good job of absorbing sound reflection, but what many folks don't understand is that it's fairly poor at dealing with sound transmission. It helps a lot that computer noise tends to be relatively high frequency, which foam is better at absorbing. As an example, an attempt to dampen out upstairs neighbors' footsteps using acoustic foam is an expensive way to do nothing. Especially as all acoustic foam is less effective the lower the frequency of the sound.
In TFA, the foam primarily seems to be used to dampen internal reflections, making the case's sound reduction more effective. E.g. foaming the inside of the venting duct helps to reduce high frequency noise escaping from the duct. Clever.
A great solution that I've used over the years is to just shove the computer into a closet, or even into the basement if the space affords it. When scouting out new living spaces, the ability to keep computers out of earshot has often been a key decision maker for me. I even got my last landlord to let me put a 4" circular port for cable passage into a closet off of a finished basement for just such purposes. Air space in the port was filled with foam discs cut to size -- open air passage between the computers and your space is to be avoided. Worked great; computers in the closet were completely inaudible more than a foot from the cable port.
As others have pointed out, the proposed position is a PR position. I want the real deal -- actual security not the appearance of it. On that note, the clueless keep making noise about Unix being "fundamentally more secure" than Windows, and that's bullshit. Let's be clear: the practical differences between OS X and WinXP in terms of security come down to the vendor's practices and the dilligence of the admins. There's no technological magic juice here. There are, IMO, zero fundamental differences between OS X and WinXP (or stock Linux) when it comes to the potential for local or remote vulnerabilities. Local and remote exploits are quite possible and practical on all these platforms.
Thus Apple has two approaches it can take. First, it can consider tactics that harden the system as a whole, making it much harder for exploits to work in the first place. Look to approaches such as those taken by grsecurity, SELinux, and the other layers found in hardened Linux and *BSD distros for examples. Harden the hell out of the kernel and compiler layers as baseline approach. Perhaps fund Coyotos work as a strategic-term approach, with an eye towards migrating the kernel. The room for innovation here is to present a hardened system that isn't any harder to use.
Second, Apple simply must be dilligent in identifying and fixing exploits. To that end, I'd propose that Apple offer a substantial first-reporter bounty for local and remote exploits on the Mac OS X platform. Think about it: set aside the equivalent salary+overhead of one or more good security experts. Divvy that amount out to leverage a larger community each year. I'd love to see a few students help pay their way through college this way. 8-)
Forget the illusion of no exploits -- go out, find 'em, and close 'em first.
I guess you could say that the reliability of software is like a wave: It goes up until a major release, then it drops down to the bottom and starts working it's way back up again.
The software company *I* work for actually manages to release damn good software for every stable release, even in the presence of major feature additions or changes. We do patch releases, but very few and largely for minor issues. Nor do we have a very long development cycle time. That "wave", while present, is barely big enough to lap at your toes.
Perhaps it's time to take a long hard look at your software development process? Or look elsewhere for a smarter dev culture?
Kodos is not yours to give...
;-)
Actually, Kodos is released under the GPL, so it *is* yours to give.
[...] for a developers interested in using Rails, updating Ruby is fairly trivial.
Another point is that many people use a custom install of Ruby to ensure that they're using the same version as their webhosting service. There's no reason to run a newer version when that just introduces an unecessary difference between your development and production environments.
Right. Like anyone in America gives a fuck about their rights and how they are losing them.
That's why an informed electorate is the lifeblood of democracy. More Americans might care, if they even had a clue what was going on or what was at stake. On just one area: How many people, left to their own devices, have the time, energy, and wherewithal to figure out the differences between trademarks vs. patents vs. copyright vs. trade secrets vs. the fiction of "intellectual property"? How many would then make the leap to form opinions and understand the changes that our government has made the last decade on issues such as the public domain, fair use, reverse engineering, patent proliferation, and so on? And after that successfully influence public policy on any matter?
If left to do their own footwork, precious few would make it past even the earliest hurdles. In and old and romantic theory, journalists serve as the advocates for the people, identifying and reporting on issues that impact the people and the public domain. There are some that still do this work, but the conflicts of interest in news media are staggering. More than distortion in news that's written, there's the story of what news stories are told and (more importantly) what aren't.
Now expand the problem from the limited scope of information rights issues to the vast panoply of domestic and international public policy issues... it's downright overwhelming. Especially considering that the few who truly get informed and become activists must combat the power of monied special interest lobbies.
It's certainly possible and worthwhile to become an informed citizen, but it takes work, and the skill to discriminate between poor and reliable news sources. Worse, going through this process challenges the comfortable platitudes dished out by the media and the major political parties. There's that choice of red pill vs. blue pill again -- stay within the comfortable zone of information control, or wake up and smell reality.
I don't get food stamps, a welfare check, my kids don't go to public schools (I don't have any), but I pay taxes that go into these programs.
The programs you cite are elements of a public welfare system available to all citizens equally based on need. The argument of the grandparent and other posters is that the CD-R tax unfairly impacts the taxed (e.g. anyone not copying music industry copyrighted content) given its stated motives. Further, the distribution of the tax's proceeds is discriminatory against large classes of the allegedly impacted (e.g. independent artists or other non-music industry content creators whose works are copied onto CD-R media).
So what? That's the story of every modern processor, because the true engineering problem is to create a synthesis of processor and compiler that produces a powerful platform. Put another way, modern general purpose processors aren't targeted at assembly programmers. Itanium, however, seems to have been plagued by outright hardware design and engineering issues above and beyond any hardware/compiler synthesis issues.
a) Hire engineers who know engineering and are crappy programmers, and make them learn programming
I disagree that this is preferable. It takes more than that same "4 years to teach them engineering" to get an untrained programmer writing code to the same standard of the hypothetical trained and experienced CS major.
This may be acceptable for some applications, esp. small, useful mathematical tools. The more sophisticated the project scope starts at (or grows to), the greater the benefit in having folks around who actually understand production software development. You really want your engineers able to focus on their engineering, and the software folks to focus on the software. Given that many engineers can code to some extent, a good developer can often write frameworks that allow the engineers to do some coding, concentrating on their problems without getting mired in aspects of software design that really aren't their specialty. In some sense, this very idea speaks directly to the success of tools popular in engineering and the sciences, such as MATLAB and Mathematica.
This is a problem with changes in legislation in the US (DMCA, etc.) that are restricting previously established reverse engineering rights for interoperability purposes. Rule: once a legal weapon is open to a corporation, they almost have to use it lest they get whalloped by the competition pulling the trigger first.
BUY an official copy of OS/X, then who the hell is Steve Jobs to tell me what I can or can't do with it?
You didn't buy a copy of OS X. Not in the same sense that you, for example, bought a frying pan or even a book. You bought a software license that comes to you under terms. As the license holder Apple can set those terms.
Note that I'm not saying that reverse engineering should be limited, or that I agree with the extension of copyright via nearly arbitrary EULA plus corporate legal power. However, being angry at Apple over these issues, or Amazon over the one-click patent, or AT&T over the XOR patent, and so on, is really a huge waste of time and energy. Consider that:
More to the point, the U.S. and other countries have established a legal environment (via laws and precedents) that resulted in the above conditions. So the question comes to mind: if you're going to direct your energy somewhere to fix these problems, is it better to rail away ineffectually at a corporation who won't hear your complaint anyway... or is it better to put that energy into altering the system that produced that corporation's behavior in the first place?
At least on Mac OS X, Firefox has some very specific problems that can contribute to this perception.
Bug 141710: Holding down mouse button forces 100% CPU on Macs is a real stinger. It it seems from discussion on this bug and a number of others that the real solution is to move Firefox on OS X off of Carbon and onto the Cocoa framework (Bug 111230: Use Cocoa for Widget instead of Carbon. That effort has an independent dev working on a port, but there seems to be little official impetus to make OS X into a first-class platform for Firefox. In response to the obvious cries of "go write code", I don't have the time and/or Cocoa knowledge to efficiently pitch in on this one. Or put another way, I don't have time to be a developer on every app that I use... %-/
I used to like Camino, and I might give it another whirl, but I've really gotten to like Firefox in many ways. I'm particularly hit by the lack of extensions or search plugins in Camino. In particular, the Web Developer Extension and Live HTTP Headers extension for FF are awesome if you have use for such things. The Sage RSS reader extension is also fairly nice.
Deja vu?
Nice quip, but the realities of the situation are completely different. My take on EPIC nee IA-64 when it was first publicly announced was surprise at an architecture that actually encouraged ultra-complex processor control logic. This, when prevailing trends tended to find ways to manage or reduce that complexity, or at least provide unambiguous chip-compiler synergy. Put another way, Intel made design choices that made the hardware itself very challenging to build and properly synergize with a compiler to achieve high total performance. Intel had certainly shown their chops at this sort of high-complexity chip controller design in the x86 line, but the move still seemed brazen from an outsider's perspective. History now shows that they certainly had trouble going down that path...
Cell, however, is basically a bog-stock PowerPC with DSP engines at its disposal. Think Altivec/MMX/SSE type units on steroids. This approach provides computing power that isn't applicable to all tasks, but is generally proven to perform well for applications that require high performance mathematical processing. Incidentally, that's precisely the target market that IBM's stated they're after with Cell-based servers. Moreover, Cell's scalability model and hardware complexities are much more managable.
To really leverage Cell's power from the software side will require some or all of 1) good compiler and toolchain support, 2) good library support, and 3) dedicated development effort for the specific application. IBM has the expertise and motivation to provide 1 and 2, and developers in the supercomputing world tend to get really good at 3. When your *highly optimized* supercomputer app may take on the order of a year to run, big emphasis tends to be put on making it run fast. Months of work to save years of time.
It still remains to be seen how this effort will play out in the marketplace, but variants of Cell's basic approach are working right now in many, many devices.
Good link, but the references get successively weaker as they shift from the relationship of close work and myopia to the effectiveness of plus lenses in halting and/or reversing the progress of myopia. Esp. number 2 and 5, with phrases such as "This is common knowledge and is covered in all vision textbooks." and "This is self-evident since the ciliary muscle has no opportunity to relax." If something is common knowledge, then provide the early seminal reference on it. Really. And NOTHING is self-evident when it comes to biological systems. (In this context, there's a trivial example: what about sleep? Eye muscles don't relax during sleep?)
The data shown for 8 is appealing, but insufficient. Numbers for the three groups are given, but what ARE those numbers? Average, median, etc? What was the distribution, statistical significance of the changes, etc? Was the study large enough and properly conducted such that the findings were statistically valid? Yes, I can go dig up the original paper, but the reference itself wasn't presented with rigor.
#9 has *no* reference to statistically validated data. Just case studies. Case studies are interesting to get an idea about a phenomenon, but you can pick and choose case studies to show *anything* -- just see the other replies to this thread for examples of that.
Last but not least, the researcher cited in #9 is none other than the creator of the site and the founder of the International Myopia Prevention Association, per their about page: http://www.preventmyopia.org/aboutus.html
Note that none of this is damning, but it takes a lot more rigor (and some chutzpah) to push though a change in the established thinking than this organization seems to be putting forth from their "validation" page.
So the question becomes: is this for real? Or is it the pipe dream of one man who hasn't found a way to conclusively prove (or disprove) his claims?
Note that I'm not trying to cast aspersions on this organization or Dr. Rehm. I'm only pointing out that it is very important to very rigorously evaluate all the random claims that one comes across these days. Conversely, it is extremely challenging to rigorously present an as-yet unaccepted scientific position.
The parent is definately correct. This is cutting edge .. many doctors still refuse to acknowledge this.
There are times that any profession, physicians included, undergoes the throes of a Khunian revolution. Consider the recent Nobel awarded to the great researchers responsible for correctly characterizing peptic ulcers as a bacterial infection. They had to fight the established dogma that ulcers were stress-related and thereby mystic and incurable.
Both the old myths of ulcers and the new urban legend of eyeglasses causing poor eyesight lacked one big thing: rigorous scientific proof. Are there *any* well-conducted, statistically valid, peer-reviewed studies that show (e.g.) that glasses worsen myopia? That reading glasses prevent or reverse the progress of myopia in children? This keeps coming up as an urban legend, and if there's no science backing it, doctors are right to "refuse to acknowledge it" -- because it's a load of bollocks!
Etymotic, with their earphones that absolutely seal into your ear canal, blocking out almost all outside noise, and putting themselves very close indeed to your eardrum.
I've been using a pair of Etymotic ER-4S headphones for about five years now. In practice, I find Ety's are far safer than normal earbuds for just the reason you cite. Since the outer part of the earbud is essentially an earplug with excellent noise blocking, the headphone doesn't have to compete volume-wise with ambient noise. You get the same clarity of sound with a lower volume level due to this.
It's also worth noting that due to the Ety's proximity to the eardrum, they don't need to be very loud at all. Their drivers run intentionally quiet for this reason. For comparison, with conventional headphones or earbuds if I set them at a comfortable listening level then set them down on the desk, I find that I can still hear the sound to some extent. With Ety's, I can't even tell whether they're on unless the volume is particularly loud or it's *very* quiet in the room.
Of course, it's critical with any headphone, Ety's or otherwise, to train yourself to moderate playback volume for extended listening.