My take as a "young developer" isn't that the kernel is too complex or that I don't like developing for the kernel (although it certainly does have its issues) as that the drawbacks outweigh the benefits. I've written device drivers for some stuff I've got laying around as well as done some board support and bringup and the experience isn't any worse than one could expect from such a task. However, working on the *mainline* Linux kernel:
a) Doesn't get me paid. b) Isn't "hip" - you don't see kernel developers speaking at media conferences or hanging out with celebrities, like you do "web 2.0 kids." The no-e-fame aspect is actually appealing for me but not for many of the people I've met. c) Involves dealing with a lot of douchebags. d) Involves wasting my time convincing an old-hands crowd self-assured of their relative place in the development world that my ideas have merit (also see c).
I "develop for the kernel" just fine, but I have no interest or desire in getting my patches to mainline - they benefit few people, Git makes it easy to track trunk while keeping my own code around, and I don't want to waste my time dealing with the douchebaggery and politics involved in reaching the mainline kernel.
This just doesn't make any sense. People who are using a social network are using a social network because they want to be found - because they want an easy way to keep in touch with a lot of people. Changing to a darknet model completely eliminates all these benefits. The only people who would buy such a device are people who shouldn't using online social networks anyway (making the import aspect odd).
Not only that, but there are actually two entirely different TI-Nspire models (Nspire and Nspire-CAS) that differ only in software (and cost).
So if it were to become possible to flash one firmware to the other, TI would both lose money and anger standardized testing organizations (most allow only the NSpire and not the CAS, and rely on the different labelling on the hardware to ensure students are using the approved unit).
DirectX is a forward-looking standard - Microsoft sits down (or stands up and yells) with developers and graphics manufacturers, and hammers out a spec which a "DirectX X.XX" card must support. Then vendors go and make a card and drivers that support those features. In this way every DirectX 10 or DirectX 11 card can be assumed to support the same things using the same APIs, and if they don't, it's the vendor's fault and they have recourse.
OpenGL, at this point, looks back - Graphics card manufacturers make a graphics card and then shoehorn its features into OpenGL. This way every single card has different supported OpenGL features implemented in different ways.
So sure, "OpenGL" gets some features first via extensions (it's debatable whether or not it's even OpenGL at that point, since the OpenGL standard doesn't even really play into it) - good luck using them, though.
The choice for game developers is pretty easy: support a lot of people (Windows and Xbox 360) using one consistent API, or support a few more people (Linux mostly, with some additional work required for PS3 or Wii) at a huge cost (debugging across vendors, platforms, and consoles).
If I want a landline, I can go buy any old phone I want, and as long as it speaks the right protocols (which are pretty simple for analog landlines) I can plug it into my wall, and it works.
It took the US government to end enforced landline phone rentals and open up the analog telephone network in 13 F.C.C.2d 420.
With today's moves towards "deregulation" I don't think we'll see the cell industry being forced to do anything similar in the near future.
Another funny point is if you were to disassemble PhysX's "GPU acceleration," you'd find that it runs very few kernels on the GPU, and that they're quite simple. What you'd also find is that there are two CPU codepaths: a non-optimized CPU codepath, and an optimized CPU codepath. The optimized CPU codepath is only taken when using the nVidia "GPU" code (which really hardly uses the GPU) - the performance improvement gained from "using the GPU" is really gained from using a non-gimped codepath!
Yes, you can do a lot of what's done on the web in "standard" HTML - but then you have to wrangle it into every "standard" browser, which turns out to be subtly different and full of bugs compared to the next.
It's not even possible to point the finger straight at Microsoft any more - Firefox has its fair share of bugs and an awful lot of non-standard DOM extensions, and every browser disables and enables a certain feature which the next supports. Support is even added and removed in certain browser sub-patchlevels and revisions - for example Safari suddenly started supporting certain DOM load events in a random security patch due to a merge of upstream WebKit.
Flash provides a common platform on which layout, interpretation, and feature support is similar (nearly identical) across all browsers on most platforms, something no other web programming solution can do.
Unfortunately that common platform isn't very good, but the homogeneity it allows is the continuing, and probably lasting appeal.
Many old datacenters have a pond and a fountain out front - and the pond isn't just to be pretty. They run the water into the fountain, and its trip thru the air cools it as it heads back into the pond.
Throwing in a shameless plug for a game I worked on - Powder Toy ( http://powder.unaligned.org/ ) - it may not be physically accurate (at all) but it's a lot of fun and would introduce them to pressure and velocity in a fun way.
Uhh... that's assuming the feds can't reverse-engineer worth a crap when they want to get a conviction. Seeing as how I know feds who can, this is wrong.
Once they've siezed the laptop (which I guess they've decided they can do now), they can do whatever they want with the drive image, including disassembling whatever boot code you had "hiding" your "hidden" partition. You need something that only -you- know, that's in your head, somewhere they can't yet reverse-engineer legally - we generally call this thing a password.
And therefore guaranteed to never receive a response! I don't think I -ever- check my voicemail unless I've accidentally missed a call I know is important, and almost nobody I know checks theirs on their personal cell either. Text messaging has replaced leaving voicemail for reminders and invitations, as it's much easier and more convenient. I think this is a service far past its time. Maybe it would have been useful in the 90s. Work is different, but this isn't exactly targeted at businesspeople.
Take some Java 1.1 source. Compile and run it with JDK/JRE 1.1. Benchmark memory consumption. Now do the same with Java 6 SE. The memory consumption for a real-world app I worked on is over 4(!) times higher with Java 6 SE. Clearly something's grown.
Kill X. Replace it with an EGL/OpenGL based windowing framework. It would provide: A unified driver architecture, already implemented by all major vendors (the ability to run GL commands). This replaces the 3000 different weird ways to do X 3D drivers these days (alternate libGL implementations vs DRI/DRM, Chromium, etc.) A programming environment many developers are already familiar with, with a far less steep learning curve than the bare X protocol (which sucks). Easy, native, non kludgy 3D interfaces and OMG 3D EFFECTS like Compiz, which seem to be the must have linux feature of today. And, X could easily be implemented on top of this framework for backwards compatibility. The XGL project even already started, with the XGl EGL backend (which was sadly abandoned, because the main aim of both the userbase and developers of XGl was to get support for OMG 3D EFFECTS on ATI/AMD cards, which because of the kludginess of X and the sketchiness of AMD linux drivers came waaay late).
Network transparency would still be possible, and maybe even easier to optimize.
so you mean... it's like windows password authentication too?! that's almost exactly how windows auth works, and that's why it's so easy to bypass with any kind of direct memory or debug access (i.e. kernel debug mode, FireWire DMA, etc.) making face authentication secure (i.e. linked to drive encryption) is a TERRIBLE idea, because faces can, do, and often change. you could get a broken nose. you could get burned. you could get slashed. you could lose teeth. you could get plastic surgery. and then you lose all your data? stupid. just like Mac OS's old voiceprint authentication, and just like the way fingerprint authentication is usually done on laptops, it's for convenience, for keeping your roommate/sibling/mom from looking through your data when you're not around, or to keep bob from down the hall from sending nasty emails from your account, without the hassle of remembering a password (or the relative insecurity of keeping a sticky note with a complicated password on the monitor, although that method is actually *very* secure against remote attacks.)
AnyDVD is reported to remove BD+.
And yes, it could, but honestly, I really do see the PS3 as a matter of security by obscurity. The PS3 was initially expensive, limiting its appeal to the "basement hacker" demographic, and most PS3 games are also available for the Xbox360, which is, for the most part, very easy to pirate games for, limiting its appeal to pirates. And it supports Linux natively, limiting the appeal of a security breach to Linux fans.
I was only halfway trying to take a jab at the PS3, really what that sentence was trying to point out was that I believe the PS3 is secure more by obscurity / a lack of an effort to break it than anything else.
Errrrr, I'm not quite sure how you call getting the encryption keys and being able to copy discs "not broken." Sure, the scheme hasn't been *cryptographically* broken, and it's possible it never will be, but if the discs can be copied (oh look: http://en.wikipedia.org/wiki/AnyDVD they can), the media companies have lost and for their purposes, it's broken.
The only current widespread, popular DRM I can think of that hasn't been broken is the copy-protection on PS3 games, and that's likely because only Sony fanboys seem to care about PS3 games.
The really funny part: Many anti-drunk-driving groups (not sure if MADD was one of them) invested in... drunk driving video (arcade) game simulators! They were often installed as part of museum exhibits and such to demonstrate the difficulty of driving drunk to kids and teenagers, I've seen at least two now (one at the Denver Museum of Nature and Science and one at some other museum, I think maybe in Dallas).
No. I actually believe that having passwords written down on a sheet of paper (*without a list of what they are for or usernames*) kept on your person is thousands of times more secure than having a single, simple (or even mildly complex) password. Sure, you could lose the sheet, but without a list of sites and your username, 99.9% of people are just going to throw the sheet out when they find it and the other.1% of people dedicated enough probably have another way in. If you use the same simple (or even complex) password stored only in your mind, one attack against one site you signed up for that doesn't hash their passwords (they still exist, even really popular ones like Photobucket) means it's all over for that password and your online user accounts. Even if you try to verify the security procedures of sites you sign up for, md5ed passwords are fairly easily broken these days (projects like NSA@Home that can process billions of keys per second combined with kids with enormous known password lists, dictionaries, and rainbow tables can crack most 12char symbol passwords" approaches.
Yes. This is how MySpace, Facebook, Photobucket, etc. are designed. It'd be very database-intensive and difficult to handle sessions/permissions every single time someone requested a static image. It's not a big deal in the case of MySpace and Facebook; the images are randomly-enough named that I don't think anyone's figured out the scheme (if there is one). Basically all it does is let you and your friend trade images of people one of you already knows, which isn't too bad considering that anyone who posts images anywhere on the internet with any expectation of privacy is pretty silly to start with. However, in Photobucket (which is insecure in general; they still store plaintext passwords amongst other issues), which doesn't rename uploaded images, it results in an amusing hobby called "fuskering" where common image sequences (i.e DCIMxxxx.JPG, etc.) can be sequentially requested from a user's account until one matches.
That's not a coprocessor.
Old Alphas just needed a different BIOS with ARC support for compatibility.
Later AlphaServers supported NT out-of-the-box with no labelled chip, custom BIOS, or differences at all from OpenVMS/OSF/1 or Linux support. I know this because I have an AlphaServer 4/266 running NT right now.
This is basically exactly what I was trying to say. Flaming projects is lame, but the projects' zealot following flaming back claiming that "you should fix it yourself" is just as lame. Many people can't fix it themselves: they are USERS. The project can not listen to their users if they want, but their rabid fanbase shouldn't flame the other users simply because they're pointing out a project's shortcomings.
This is 100% exactly the same argument presented whenever an Open Source app is criticized. Shut up about it! How about instead of whining about people whining about their software, Rails advocates fix some of the issues causing arguments against their framework? Most of the people whining aren't capable of writing their own code to fix their problems with Rails, but their rants should be taken as SUGGESTIONS by the developers, not railed (no pun intended, seriously) against by a community full of zealots. The same applies to all of the OSS fanatics who make this argument about *every* *single* *piece* of software, ever. Yeah, sure, people should be a little more grateful. But does the project being free protect it from criticism? It shouldn't.
Maybe you should go read up on the changes Apple has made between firmware versions. They're well-documented by the iPhone community, and they aren't "OS revisions improving." Half of it is the ghetto way in which functions were initially used (the API isn't changing, but the method of calling the API initially required a relink for each version), and half of it is Apple *very clearly and deliberately removing third-party app capability as each version comes out, not the API changing* I won't debate if that's the "right thing" for Apple to do, but that's what they're doing. Don't try to make them excuses.
Slashdot Mirror
I tried it for a few minutes, and the Prius never suddenly accelerated. Clearly the simulation is flawed.
My take as a "young developer" isn't that the kernel is too complex or that I don't like developing for the kernel (although it certainly does have its issues) as that the drawbacks outweigh the benefits. I've written device drivers for some stuff I've got laying around as well as done some board support and bringup and the experience isn't any worse than one could expect from such a task. However, working on the *mainline* Linux kernel:
a) Doesn't get me paid.
b) Isn't "hip" - you don't see kernel developers speaking at media conferences or hanging out with celebrities, like you do "web 2.0 kids." The no-e-fame aspect is actually appealing for me but not for many of the people I've met.
c) Involves dealing with a lot of douchebags.
d) Involves wasting my time convincing an old-hands crowd self-assured of their relative place in the development world that my ideas have merit (also see c).
I "develop for the kernel" just fine, but I have no interest or desire in getting my patches to mainline - they benefit few people, Git makes it easy to track trunk while keeping my own code around, and I don't want to waste my time dealing with the douchebaggery and politics involved in reaching the mainline kernel.
This just doesn't make any sense. People who are using a social network are using a social network because they want to be found - because they want an easy way to keep in touch with a lot of people. Changing to a darknet model completely eliminates all these benefits. The only people who would buy such a device are people who shouldn't using online social networks anyway (making the import aspect odd).
Not only that, but there are actually two entirely different TI-Nspire models (Nspire and Nspire-CAS) that differ only in software (and cost).
So if it were to become possible to flash one firmware to the other, TI would both lose money and anger standardized testing organizations (most allow only the NSpire and not the CAS, and rely on the different labelling on the hardware to ensure students are using the approved unit).
DirectX is a forward-looking standard - Microsoft sits down (or stands up and yells) with developers and graphics manufacturers, and hammers out a spec which a "DirectX X.XX" card must support. Then vendors go and make a card and drivers that support those features. In this way every DirectX 10 or DirectX 11 card can be assumed to support the same things using the same APIs, and if they don't, it's the vendor's fault and they have recourse.
OpenGL, at this point, looks back - Graphics card manufacturers make a graphics card and then shoehorn its features into OpenGL. This way every single card has different supported OpenGL features implemented in different ways.
So sure, "OpenGL" gets some features first via extensions (it's debatable whether or not it's even OpenGL at that point, since the OpenGL standard doesn't even really play into it) - good luck using them, though.
The choice for game developers is pretty easy: support a lot of people (Windows and Xbox 360) using one consistent API, or support a few more people (Linux mostly, with some additional work required for PS3 or Wii) at a huge cost (debugging across vendors, platforms, and consoles).
If I want a landline, I can go buy any old phone I want, and as long as it speaks the right protocols (which are pretty simple for analog landlines) I can plug it into my wall, and it works.
It took the US government to end enforced landline phone rentals and open up the analog telephone network in 13 F.C.C.2d 420.
With today's moves towards "deregulation" I don't think we'll see the cell industry being forced to do anything similar in the near future.
Another funny point is if you were to disassemble PhysX's "GPU acceleration," you'd find that it runs very few kernels on the GPU, and that they're quite simple. What you'd also find is that there are two CPU codepaths: a non-optimized CPU codepath, and an optimized CPU codepath. The optimized CPU codepath is only taken when using the nVidia "GPU" code (which really hardly uses the GPU) - the performance improvement gained from "using the GPU" is really gained from using a non-gimped codepath!
"Standard HTML" is sort of an oxymoron.
Yes, you can do a lot of what's done on the web in "standard" HTML - but then you have to wrangle it into every "standard" browser, which turns out to be subtly different and full of bugs compared to the next.
It's not even possible to point the finger straight at Microsoft any more - Firefox has its fair share of bugs and an awful lot of non-standard DOM extensions, and every browser disables and enables a certain feature which the next supports. Support is even added and removed in certain browser sub-patchlevels and revisions - for example Safari suddenly started supporting certain DOM load events in a random security patch due to a merge of upstream WebKit.
Flash provides a common platform on which layout, interpretation, and feature support is similar (nearly identical) across all browsers on most platforms, something no other web programming solution can do.
Unfortunately that common platform isn't very good, but the homogeneity it allows is the continuing, and probably lasting appeal.
Many old datacenters have a pond and a fountain out front - and the pond isn't just to be pretty. They run the water into the fountain, and its trip thru the air cools it as it heads back into the pond.
Throwing in a shameless plug for a game I worked on - Powder Toy ( http://powder.unaligned.org/ ) - it may not be physically accurate (at all) but it's a lot of fun and would introduce them to pressure and velocity in a fun way.
Uhh... that's assuming the feds can't reverse-engineer worth a crap when they want to get a conviction. Seeing as how I know feds who can, this is wrong.
Once they've siezed the laptop (which I guess they've decided they can do now), they can do whatever they want with the drive image, including disassembling whatever boot code you had "hiding" your "hidden" partition. You need something that only -you- know, that's in your head, somewhere they can't yet reverse-engineer legally - we generally call this thing a password.
And therefore guaranteed to never receive a response!
I don't think I -ever- check my voicemail unless I've accidentally missed a call I know is important, and almost nobody I know checks theirs on their personal cell either.
Text messaging has replaced leaving voicemail for reminders and invitations, as it's much easier and more convenient.
I think this is a service far past its time. Maybe it would have been useful in the 90s.
Work is different, but this isn't exactly targeted at businesspeople.
Take some Java 1.1 source.
Compile and run it with JDK/JRE 1.1.
Benchmark memory consumption.
Now do the same with Java 6 SE.
The memory consumption for a real-world app I worked on is over 4(!) times higher with Java 6 SE.
Clearly something's grown.
Kill X. Replace it with an EGL/OpenGL based windowing framework.
It would provide:
A unified driver architecture, already implemented by all major vendors (the ability to run GL commands). This replaces the 3000 different weird ways to do X 3D drivers these days (alternate libGL implementations vs DRI/DRM, Chromium, etc.)
A programming environment many developers are already familiar with, with a far less steep learning curve than the bare X protocol (which sucks).
Easy, native, non kludgy 3D interfaces and OMG 3D EFFECTS like Compiz, which seem to be the must have linux feature of today.
And, X could easily be implemented on top of this framework for backwards compatibility. The XGL project even already started, with the XGl EGL backend (which was sadly abandoned, because the main aim of both the userbase and developers of XGl was to get support for OMG 3D EFFECTS on ATI/AMD cards, which because of the kludginess of X and the sketchiness of AMD linux drivers came waaay late).
Network transparency would still be possible, and maybe even easier to optimize.
so you mean... it's like windows password authentication too?! that's almost exactly how windows auth works, and that's why it's so easy to bypass with any kind of direct memory or debug access (i.e. kernel debug mode, FireWire DMA, etc.)
making face authentication secure (i.e. linked to drive encryption) is a TERRIBLE idea, because faces can, do, and often change. you could get a broken nose. you could get burned. you could get slashed. you could lose teeth. you could get plastic surgery. and then you lose all your data? stupid.
just like Mac OS's old voiceprint authentication, and just like the way fingerprint authentication is usually done on laptops, it's for convenience, for keeping your roommate/sibling/mom from looking through your data when you're not around, or to keep bob from down the hall from sending nasty emails from your account, without the hassle of remembering a password (or the relative insecurity of keeping a sticky note with a complicated password on the monitor, although that method is actually *very* secure against remote attacks.)
AnyDVD is reported to remove BD+. And yes, it could, but honestly, I really do see the PS3 as a matter of security by obscurity. The PS3 was initially expensive, limiting its appeal to the "basement hacker" demographic, and most PS3 games are also available for the Xbox360, which is, for the most part, very easy to pirate games for, limiting its appeal to pirates. And it supports Linux natively, limiting the appeal of a security breach to Linux fans. I was only halfway trying to take a jab at the PS3, really what that sentence was trying to point out was that I believe the PS3 is secure more by obscurity / a lack of an effort to break it than anything else.
Errrrr, I'm not quite sure how you call getting the encryption keys and being able to copy discs "not broken." Sure, the scheme hasn't been *cryptographically* broken, and it's possible it never will be, but if the discs can be copied (oh look: http://en.wikipedia.org/wiki/AnyDVD they can), the media companies have lost and for their purposes, it's broken.
The only current widespread, popular DRM I can think of that hasn't been broken is the copy-protection on PS3 games, and that's likely because only Sony fanboys seem to care about PS3 games.
The really funny part: Many anti-drunk-driving groups (not sure if MADD was one of them) invested in... drunk driving video (arcade) game simulators! They were often installed as part of museum exhibits and such to demonstrate the difficulty of driving drunk to kids and teenagers, I've seen at least two now (one at the Denver Museum of Nature and Science and one at some other museum, I think maybe in Dallas).
No. .1% of people dedicated enough probably have another way in.
I actually believe that having passwords written down on a sheet of paper (*without a list of what they are for or usernames*) kept on your person is thousands of times more secure than having a single, simple (or even mildly complex) password. Sure, you could lose the sheet, but without a list of sites and your username, 99.9% of people are just going to throw the sheet out when they find it and the other
If you use the same simple (or even complex) password stored only in your mind, one attack against one site you signed up for that doesn't hash their passwords (they still exist, even really popular ones like Photobucket) means it's all over for that password and your online user accounts. Even if you try to verify the security procedures of sites you sign up for, md5ed passwords are fairly easily broken these days (projects like NSA@Home that can process billions of keys per second combined with kids with enormous known password lists, dictionaries, and rainbow tables can crack most 12char symbol passwords" approaches.
Yes. This is how MySpace, Facebook, Photobucket, etc. are designed. It'd be very database-intensive and difficult to handle sessions/permissions every single time someone requested a static image.
It's not a big deal in the case of MySpace and Facebook; the images are randomly-enough named that I don't think anyone's figured out the scheme (if there is one). Basically all it does is let you and your friend trade images of people one of you already knows, which isn't too bad considering that anyone who posts images anywhere on the internet with any expectation of privacy is pretty silly to start with.
However, in Photobucket (which is insecure in general; they still store plaintext passwords amongst other issues), which doesn't rename uploaded images, it results in an amusing hobby called "fuskering" where common image sequences (i.e DCIMxxxx.JPG, etc.) can be sequentially requested from a user's account until one matches.
That's not a coprocessor. Old Alphas just needed a different BIOS with ARC support for compatibility. Later AlphaServers supported NT out-of-the-box with no labelled chip, custom BIOS, or differences at all from OpenVMS/OSF/1 or Linux support. I know this because I have an AlphaServer 4/266 running NT right now.
This is basically exactly what I was trying to say. Flaming projects is lame, but the projects' zealot following flaming back claiming that "you should fix it yourself" is just as lame. Many people can't fix it themselves: they are USERS. The project can not listen to their users if they want, but their rabid fanbase shouldn't flame the other users simply because they're pointing out a project's shortcomings.
This is 100% exactly the same argument presented whenever an Open Source app is criticized.
Shut up about it!
How about instead of whining about people whining about their software, Rails advocates fix some of the issues causing arguments against their framework? Most of the people whining aren't capable of writing their own code to fix their problems with Rails, but their rants should be taken as SUGGESTIONS by the developers, not railed (no pun intended, seriously) against by a community full of zealots.
The same applies to all of the OSS fanatics who make this argument about *every* *single* *piece* of software, ever.
Yeah, sure, people should be a little more grateful.
But does the project being free protect it from criticism? It shouldn't.
Maybe you should go read up on the changes Apple has made between firmware versions.
They're well-documented by the iPhone community, and they aren't "OS revisions improving."
Half of it is the ghetto way in which functions were initially used (the API isn't changing, but the method of calling the API initially required a relink for each version), and half of it is Apple *very clearly and deliberately removing third-party app capability as each version comes out, not the API changing*
I won't debate if that's the "right thing" for Apple to do, but that's what they're doing. Don't try to make them excuses.
Akami forwards the header strings from whatever httpd the Akami network is caching/fronting for.
http://news.netcraft.com/archives/2003/08/17/wwwmicrosoftcom_runs_linux_up_to_a_point_.html