Comment Re:my mother quit when she was pregnant (Score 2) 155
what does this mean.
what does this mean.
Didn't say it was. I just said NASA should abandon it to whomever wants to pay to keep it operating. Prettty sure its past its original end of life anyway which I think was 2010.
If Russia doesn't want to play nice, or pay to run it themselves, I doubt ESA, Canada or Japan will be able to keep it going if the U.S. pulls out.
It's too late now, but if this device had been encrypted before it was broken, you'd have a lot less to worry about.
OTOH, it's worth pointing out that if the level of effort required to find the storage on the broken device so you can wipe or destroy it is too much to bother with, it will almost certainly be too much effort for anyone to go through the same effort in order to retrieve your data, on the off chance there might be something of value in there somewhere.
You don't have to understand everything, but you do need to at least understand the basics, like how networking works, how crypto works, etc. at a conceptual level. I feel like too many developers learn how to program by learning JavaScript and other scripting languages on their own, then jump into app programming thinking that it's only one step harder because you can sort of do it in Python/Ruby/other Obj-C bridged languages/other
Too many developers then balk when we tell them that they need to read conceptual books, insisting that they just want to learn how to solve their particular problem. The result is that they understand just enough of what they're doing to be dangerous. It's like deciding to build a house and telling someone, "I just want to know how to cut a board and hammer in a nail." You're likely to get a very strange looking house with no right angles. You really need to start with higher-level design and philosophy texts, then work your way down to the practical texts. That's equally true in programming, but the short-attention-span instant-gratification crowd just doesn't get that.
And I understand the desire to just learn how to solve the problem. I've been there, and I've done that, but only in areas where I was reasonably comfortable. Even then, I've often later discovered that snippets that looked right weren't quite right in certain edge cases, but at least this happens fairly infrequently, because I've taken the time to learn what I'm doing. Developers who don't do this aren't just hurting themselves; they're hurting their users. There's just no reason for that.
Whether Symbian is a good platform or not involves more than just if the code is functional. Sometimes a lack of applications is driven by a more fundamental weakness in a platform. One of the reasons the iPhone and iPad have done so well courting application developers is that Apple tries to keep everyone marching in formation, moving the platform forward without leaving current customers too far behind. (Their formation, of course, but they are Apple)
A good example is the "pixel doubing" that went into the early iPad design. That intentionally structured the design of the platform so that applications written for lower resolutions would continue working against the higher pixel counts. That's the sort of subtle thing you do to keep developers happy and application development flourishing.
Faced with the same sort of devices with multiple resolutions problem, Android leaves the whole mess in the lap of application developers. And Nokia has just abandoned the old stuff. If you're a phone developer, how would you feel about that? A lot of things like that influence whether applications are built for a platform or not.
And, yes, Microsoft has bullied their way into a winning position using their operating system monopoly for a long time, with IE being a good example of that. I don't think it's safe to assume that tactic will keep working anymore though. I don't know anyone who feels Windows compatibility is an important thing on their phone or tablet today. At best, I might want something that opens Word or Powerpoint documents someone sends me in an e-mail. You don't need Microsoft for that on your phone though. Their software is only needed if you expect to edit the documents with low risk of corruption, and that still happens on desktops.
You've got the worse decision-making that I've seen in the last 20 years.
You must not have have been following the Nokia story until now then.
Seems to involve Elop burning another platform. I wouldn't let that man develop a "framework" to do my laundry.
Code recycling is one thing, but not understanding what that code does when you put it into a production app or not following best practices is another. As Android gains popularity as a platform to develop for, we're going to lose quality as the new folks jumping onto the band wagon don't care how their apps work or look beyond the end goal. This mentality is already popping up with Android Wear developers who cram as much information as they can on the screen and claim that design guidelines are "just recommendations."
The exact same thing happens on every other platform, though perhaps to varying degrees. I refer to it as the Stack Overflow effect. One developer who doesn't know the right way to do something posts a question. Then, a developer who also doesn't know the right way to do it posts how he or she did it. Then ten thousand developers who don't know the right way to do it copy the code without understanding what it does or why it's the wrong way to do it. By the time somebody notices it, signs up for the site, builds up enough reputation points to point out the serious flaw in the code, and actually gets a correction, those developers have moved on, and the bad code is in shipping apps. Those developers, of course, think that they've found the answer, so there's no reason for them to ever revisit the page in question, thus ensuring that the flaw never gets fixed.
Case in point, there's a scary big number of posts from people telling developers how to turn off SSL chain validation so that they can use self-signed certs, and a scary small number of posts reminding developers that they'd better not even think about shipping it without removing that code, and bordering on zero posts explaining how to replace the SSL chain validation with a proper check so that their app will actually be moderately secure with that self-signed cert even if it does ship. The result is that those ten thousand developers end up (statistically) finding the wrong way far more often than the right way.
Of course, it's not entirely fair to blame this problem solely on sites like Stack Overflow for limiting people's ability to comment on other people's answers unless they have a certain amount of reputation (a policy that is, IMO, dangerous as h***), and for treating everybody's upvotes and downvotes equally regardless of the reputation of the voter. A fair amount of blame has to be placed on the companies that create the technology itself. As I told one of my former coworkers, "The advantage of making it easier to write software is that more people write software. The disadvantage of making it easier to write software is that... more people write software." Ease of programming is a two-edged sword, and particularly when you're forced to run other people's software without any sort of actual code review, you'd like it to have been as hard as possible for the developer to write that software, to ensure that only people with a certain level of competence will even make the attempt—sort of a "You must be this tall to ride the ride" bar.
To put it another way, complying with or not complying with design guidelines are the least of app developers' problems. I'd be happy if all the developers just learned not to point the gun at other people's feet and pull the trigger without at least making sure it's not loaded, but for some reason, everybody seems to be hell-bent on removing the safeties that would confuse them in their attempts to do so. Some degree of opaqueness and some lack of documentation have historically been safety checks against complete idiots writing software. Yes, I'm wearing my UNIX curmudgeon hat when I say that, but you have to admit that the easier programming has become, the lower the average quality of code has seemed to be. I know correlation is not causation, but the only plausible alternative is that everyone is trying to make programming easier because the average developer is getting dumber and can't handle the hard stuff, which while possible, is even more cynical than the original assertion and makes me weep for the future.
Either way, there's something really, really wrong at a fundamental level with the way we search for solutions to coding problems. There needs to be an easy way to annotate the fact that a code snippet was derived from a particular forum post, and to automatically receive email notifications (or bug reports) whenever someone flags the snippet on the original forum as being wrong or dangerous. And we as developers need to take the time to learn enough about the OS and the programming environment to ensure that we at least mostly understand what a piece of code does before we ship it in a product.
Now, now, now, it's not the version control system's fault that you checked in a bug....
Dr. Bose did a lot of groundbreaking research back in the day. And, yes, nobody wastes $100M in audio research the way Bose does.
The problem is that none of that is reflected (heh heh) very well by their product line. You can't prove anything from a one-off sample in their office. The real key to home audio isn't cost no object performance; it's bang for the buck in real-world production. And it's there that Bose's products are sketchy, and the way they sue anyone who measures that fact should set off a warning light. All the money going into R&D is part of the problem--that's overhead that doesn't fund itself unless it's turned into product innovation. And it didn't in this particular case; the most fundamental patent in this lawsuit set is one Bose purchased , not developed. Not exactly a high point in Bose R&D history.
I'd like to discuss the lack of innovation in Bose audio products in objective terms, but their very deep flaws prevent that from even being possible. They don't use the standard measurements for speakers everyone else in the industry does. Their theater products ignore the THX specifications everyone else adopted. That pattern is everywhere at Bose. You can either believe in the ancient Bose mythology of not measuring speakers, or you can agree that the concrete numbers every other audio researcher in the world uses are important. Read some papers by Dr. Floyd Toole if you want to find out about reflected sound from someone in the speaker manufacturing R&D business who moved past the 60's.
Dr. Bose was a smart dude, but smarter than every other researcher put together? That's a very special breed of arrogance. I'll take the side of scientific consensus, thank you.
Bose didn't even file that patent--they bought it, presumably because they realized it was so general they could sue people all kinds of people when they felt like it. Bose: better sound through patent extortion!
Probably one of the best things NASA could do at this point is abandon ISS, stop paying for it, and tell the Russians its all theirs. There is a fair chance they would fly Americans to it for free rather than get saddled with that boat anchor.
If the Russians don't want it either its time to deorbit it. It would free up a LOT of money for more useful endeavors. Its never been good for much of anything, certainly nothing to justify the staggering price tag
SpaceX will have the ability to put astronauts in to LEO in a few years. Its not like its a crisis, there is very little for people to do in LEO at the moment other than to be lab rats for zero G physiology studies. You would think they would have done most of that work by now.
About the only point in putting people in space at all is as colonists, persumably on Mars. You can do just about everything else way better and cheaper with robots.
So until you are ready to fly people to Mars to stay, stop getting your panties in a bunch about getting them to LEO.
That doesn't have anything to do with the lawsuit. Bose's early patents on noise reduction had a fairly wide scope to them, trying to own the entire territory of reducing aircraft noise independently of the signal. They might even have been able to claim some sort of domain over anyone who plays headphones without music; I wasn't following patent silliness back then. But those products have been shipping since 1989, so any really fundamental patent in that area expired years ago.
What Bose did then was either file or acquire a series of patents on the obvious ways to build digital circuits for such noise reduction. You can't build any digital noise reduction system without tripping over at least one of them. In the tech industry, there are all these "on a computer!" patents people like to complain about. In audio, their version of that tactic is to patent some math in the form of a "Digital Signal Processing System". The first one is really blatant in that regard. Basically anyone who builds a digital circuit with things like a FIR filter and applies it to audio noise reduction can expect a patent infringement. And Bose didn't even develop that one; they bought the patent specifically for the sort of extortion they're doing here, in the usual way Bose sues companies frivolously.
It could be worse for Beats--they could have also violated Bose's highly innovative use of
It is better to never have tried anything than to have tried something and failed. - motto of jerks, weenies and losers everywhere
