Why not just a physical (non toggle) button that enables a unit-specific password for two hours? You might have a big sticker next to the button with that machine's login info. Gain physical access to the device, and you gain access to the router. Have the machine send an e-mail out the the administrators whenever this happens. You would have to trust your employees, but if you can't trust them you are doing something very wrong.
You're making some big assumptions here, for one that "employees" are the only ones who are going to be near your routers.
Wireless access is becoming more and more pervasive -- you see routers in homes, coffeeshops, libraries, bookshops, airports, etc. etc..
Do you want to require librarians to keep a constant watch over their routers, protecting them from teenagers with paperclips?
It's not as dangerous to have a full reset button, because it's hard to do a hard reset on a router without people noticing. But a single click that enables a full admin account, with no effect on other users? No, thanks. Even the email idea is no good; the emailing functions require setup that most users don't bother with (I didn't, at least -- I don't have time for reading logs).
Sure there is. The reset button will nuke the configuration, the logs, and whatever else state is there, thus confounding debugging by the tech support. A single password is stupid, though. What's needed is something that requires the router s/n, the router's idea of the date, and a passcode generator from cisco. Give the aforementioned info to cisco TS and they can generate a 1 or 2 hour passcode for your router. You could also add a switch to enable this feature on the router itself, but that may not be practical.
I'm not convinced. This is only a concern in cases where you're having technical problems, AND you somehow forgot your password. The danger of having a backdoor easily outweighs the potential benefits. Even with a special password generator from NetGear -- you're still talking security through obscurity. I want to set up my router, make sure it's secure, and forget about it! I don't want to keep checking online to see if you can download N3tg34r_PwG3n.exe yet... and you know it's going to show up eventually.
Half the time you have any technical issues, the tech support is just going to tell you to do a hard reset anyway....
Even if they gave you one of those paperclip-hole style buttons that would reset all your passwords to your device's serial number (or to enable some other backdoor), this would still be dangerous in a lot of situations. Suppose you're running an internet cafe -- you can't always trust the people sitting around your router!
Either way, I don't think this backdoor was installed for tech support reasons -- it doesn't even seem to have been installed by NetGear themselves. Hopefully some more details will come out soon... and hopefully some heads will roll.
It's funny; I just read that new story by the AdTI guy explaining how Linux wasn't safe to use because it depended on "trust". Hah! How nice for the corporate world to step forward and show that *they* can be trusted.
that "noone" is not a word? He uses it repeatedly, so it's clearly not a typo.
Perhaps he and I can meet at Ye Olde Sandwyche Shoppe at noone to discuss this, as well as his interesting discussion of "hybrid source".
I like it how open source is dangerous because we have to have some degree of "trust" that developers aren't adding in other people's IP. Whereas private corporations developing closed source applications, with a financial incentive to steal others' IP and no easy way to get caught will be struck down by God if they do it, so we don't need to depend on "trust".
This would be interesting on a computer, but would be fairly hard to do in print.
That was my thought too, and there are lots of examples of 3d crosswords online (try Google; for example this). If you have the wherewithal to code it yourself, or if you find a plugin you can use -- I'd say make your puzzle available online, then in the newspaper just put an intriguing screenshot and a link (tinyurl?) that readers can visit to try solving it.
It's not the capabilities of jMusic or the Java Sound API that led them to Java. If you just balance a list of capabilities in the musical realm, there are plenty of specialty languages and environments -- i.e., MAX, PD, ChucK, and so on -- that have greater built-in capabilities, because they are languages or scripting engines focussed only on music. That's also the downside of those languages, though; they are specialty languages.
In '97-'98 I wrote a bunch of music theory training programs for the Music department at my school (they eventually became this website), and I tried out MAX first before I went with Java. MAX was far better equipped to handle the music-related requirements (anyone remember Java 1.0.2?). But with Java I could put my applets online, run them on any OS, and (biggest bonus) get some serious experience in a language that would get me my first job when I got out of college. Learning a new language to a level where you can tackle an ambitious project is a big investment. There are a lot of musicians and composers with day jobs as developers (like me) who want to be able to leverage what they already have, if feasible. And nowadays, Java has pretty good support for audio, as general-purpose languages go, so many projects wouldn't be giving up much to use Java.
Here are a few snippets from the jMusic website that suggest why they chose Java for their project:
Programming in jMusic is programming in Java, not in a meta-language or scripting environment. This means that the full power and cross platform independence of Java is maintained, it also means that the more you know about Java programming the more useful jMusic will be to you. Learning jMusic can be a fun way to gain Java programming skills while focusing on making music.
[...]Because jMusic has full access to the Java language and support structures, your jMusic work can be as extensive as Java allows (and that is VERY extensive).
There are more hints at this in the intro of the article, as well.
I probably did exaggerate the situation a bit -- it's definitely a two-way interaction b/w MS and the hardware manufacturers. But the point still stands that it's a direct, active interaction. Some hardware manufacturers complained to MS for dropping support, some figured they could make some revenue if users were forced to upgrade to their absolute newest model... but they were all involved, and made the choice of releasing new drivers for older models, encouraging upgrades, or whatever.
You don't hear of a new Linux distro that makes huge changes to their driver model, because
a) people wouldn't switch to it without support for their older hardware, and
b) the hardware vendors wouldn't care, and wouldn't even think about putting development time into making sure their old models were supported.
I'm not an expert on this subject... but I think I have a good point here.
I agree that is wasn't FUD in the normal sense. I think he gave a fairly reasonable account of his experience.
On the other hand, he spoke of Microsoft's support for all new hardware as if it meant that Windows was a better product, as if compatibility with new hardware was one of MS's technical achievements.
I'll keep trying. Eventually, someone will release something that will work on my system. More generally, someday, Linux will probably catch up with Microsoft's broad support for mainstream hardware.
This is a pretty close-minded view of the situation.
The fact is that it's primarily the new hardware which is designed and tested to be compatible with Windows, not the other way around. Can you imagine a vendor releasing a new soundcard without testing to make sure it worked on all major Windows variants? Of course not. If there are bugs in the Windows 98 drivers, the hardware vendor will work around them... even if that might mean breaking the standard interface. It's a no-brainer, considering what OS their average customer runs.
So Fred is on target with his main criticism, though he doesn't understand the chicken & egg nature of the problem. And I tend to agree with him that Linux vendors should keep prices low, partly because they can't offer quite the same experience yet, but also partly because as Linux spreads, the compatibility problem will just go away on its own. Once the hardware vendors are losing significant sales because their product can't be run on Linux, they will sit up and take note.
I'm guessing this is only available in the nightly builds for now, since I just hopped over to the site and there's no sign of a new milestone release (would be M9).
So... don't get excited -- the feature is *coded*, but you can't use it yet. That is, I haven't tried an Eclipse nightly before, but in general it's a bad idea if you're depending on the tool.
It looks like the latest integration build (a step up from a nightly) is still failing its tests.
In my experience, even some of the milestone builds have been a tad flaky (I put up with it because I want the features).
Anyone involved in the project know anything about when the next milestone release is planned?
Of course, a object only gets collected when it is no longer reachable. If any reference, static or not, remains reachable from the applications root objects, that object is not collected.
Right. The tricky aspect of static references that I'm trying to point out is that they're *always* reachable by those root objects, so a static reference must be explicitly nulled to free the object it refers to. This is different from normal references in object instances, which are collected along with the instance. For example -- java.awt.Color has static members white, black, etc. - each of the static references refers to an instance of the class Color. Once java.awt.Color is referenced anywhere, all of those objects will be created, and they won't be destroyed until the JVM shuts down; it doesn't matter if the instance of Color that you were using is garbage collected. See what I'm talking about? You can reference Color.white from anywhere, so it can't be collected.
So, you likely want to say that having static references might be a cause for programm errors/memory leaks?
It can be, if the coder doesn't understand what the static modifier does. I've seen code where the member variables of a class were declared static for no reason I could see, since they were accessed as if they were non-static. This caused strange errors occasionally -- when two separate instances of the class found themselves modifying the same member object (because it was static, there was only one shared by all instances). If this error were widespread, and lots of objects had these mistaken static references, then memory usage could be dramatically increased because even though the instances were GC'd, their members never could be (because they were static).
This isn't a common problem, I don't think. It just came to mind as one of the many ways your code choices will affects what the VM can do with memory.
Yes, indeed, but it is also not necessary to null away attribute references of other objects. Some people seem to think in a GC environment you have to manually null every reference to an object.... or it wont get collected soon enough.
Correct. Assuming all non-static references, once an object is no longer accessible, that means its members aren't accessible either, and the whole thing is eligible for collection.
I can clarify some of my points, and give examples. None of these are hard and fast rules, by the way -- it all does depend on what you're doing, and what you need. I do NOT advocate making your code unmaintainable for the sake of questionable optimizations.
Most of the time you absolutely do not need to consider anything you preach here. First reason: all objects in Java live on the heap. So you simply can't do anything about it.
Correct, many times you *don't* need to worry about memory in Java at all, especially in client-side applications. Server-side, though, it often helps to know a little more. I'm not sure what you mean by "there's nothing you can do about" the objects on the heap... your design can have a large effect on how many objects are created, how big they are, and how long they stay on the heap. If you are processing a massive resultset from a sql query, creating a complex hierarchy of objects that each knows how to process a certain type of row, and creating one for each row, will throw a lot of objects onto the heap, and you'll get a lot more churn. If you store each one in a collection to process after you're done reading, then the garbage collector can't touch them yet, and instead of churn, your heap just grows a lot.
Static variables get collected just like non static ones. Think about a static references to a large object. Even when all instances of class "Foo" have been GC'ed, that reference to "bigThing" remains, and bigThing is not eligible for collection, until you specifically set Foo.bigThing = null. It's not necessarily bad -- maybe there are lots of instances of Foo that all use bigThing, and you want to keep it on the heap.
Third: why does everybody repeat the myth of "carefully nulling references"? You assign null if you WANT the reference to be null, and you don't null to assist teh GC. Nulling does not assist, it only costs runtime
I'll check my post again, but I think I said that people who carefully null references are *wasting their time*. Nulling out variables *technically* does affect GC (because an object is "dead" and ready to collect when all references to it are gone), but there's usually no reason to null a local variable for this reason, because it's going out of scope in a few millisecs anyway.... and likely thats why you claim Java si slow. Java isn't slow at all! I do most of my server-side work in Java, and it's pretty zippy and very scalable. Anyway...
This one beats it all. Sure you need a thread pool. Creating a new thread, does not only allocate a thread object, but it likely makes a kernel call to get a new thread handle. You pool to avoid the kernel call. Not to avoid the memory allocation/deallocation.
I said "probably". If you're writing a webserver or something like that, which otherwise would create scads of threads and only use them for a short time, yes. (Object pool, never -- but thread pool, sometimes). In most other applications, a thread pool is just adding complexity (especially if you write it yourself).
How long do you think it really takes to allocate a new Thread (system call, memory and all)? It's less than a millisecond; on my old laptop it's about 1/5th of a millisecond. Try it out. Even if your app creates a new Thread every 10 seconds, you're probably wasting your time with a thread pool, and you should be optimizing your SQL instead.
of course a very restricted set of applications do need to scale, but for most applications being developed by [novice coders it is] perfectly alright, because in practice the result is that memory management actually _is_ all handled for them.
Yeah, I think I clicked "Reply" with the idea of giving a few GC pointers, and ended up with a weird kind of elitist rant. I love GC, and it's totally worth the few tradeoffs (which are more education issues than anything else).
You might be minimizing the number of projects that need some level of scaleability, though. Any server-centered technology (i.e., interactive website) is based on scaling -- thin client, all the work done on the server, that sort of thing. Though I guess it comes down to this: I have seen a lot of projects coded by people who probably weren't ready for them yet... but that happens everywhere, and that's why projects have a crazy failure rate, and it isn't a problem specific to GC in any way.
While you are entirely right, this is no differnt from previous generations of programming languages
Fair enough, though if you don't understand memory management in C you will know it, because you'll have massive memory leaks or serious, noticeable bugs.
I think I mistakenly gave the impression that I don't like GC. I love it, and I think it's definitely worth the few drawbacks -- I just wanted to point out that it's not a silver bullet. And I do get frustrated with inexperienced programmers who speak scornfully of how slow Java is compared with C or C++, because their own class projects were slow...
Good article, though very limited in scope (basically just a list of GC methods, wrapping up with the methods used by recent Java and.NET interpreters). I was a little disappointed that they didn't get into the implications of using languages with GC.
One pitfall that I've noticed basically comes along with the benefit of avoiding "micro-managed" explicit memory management -- there are a lot of Java coders who don't think at *all* about memory management, because they think it's all handled for them. Mix that in with an over-excitement about OO, and you get some impressively slow and non-scaleable code.
You DO need to understand, at least on a basic level, what's going onto the heap, and what the garbage collector has to do to keep up with your "garbage". Carefully nulling out objects that are going to be out of scope in a millisecond is just wasting space, but you should definitely keep an eye on what objects you're allocating within that loop that runs a million times. They're all going on the heap; are they all going to be on there at the same time? When are they going to be eligible for collection? Are they just Strings, or larger objects (which possible create other objects when they are created)?
If you have to optimize a section of code, consider sticking to primitives and Strings (obviously you're balancing this against the cost of possibly less-maintainable code!), and don't forget that when you instantiate com.foo.Bar, all of its superclasses are also instantiated, including any member objects they hold. And don't make a variable static for no reason -- it won't get collected with the object instance....
Two useful things to think about -- heap size (the objects you're actively using at a given moment, so they can't be collected), and churn rate (how fast you're creating and trashing objects). Object creation/destruction isn't as costly as it was with the early versions of Java (no, you probably don't need that Thread pool!). But any application that needs to scale requires some thought on memory usage and churn before you start coding.
I graduated with a degree in Music composition and performance, which I very much enjoyed. I took other classes all across the board, trying to get everything I could out of college. When I graduated I got a job as a Java developer (based mostly on non-academic programming projects I did). Now I'm doing quite comfortably.
I may get an MBA a bit down the road, since it would make a nice complement to my programming experience (and what I've already learned about how business works, on the job)... but the point here is that if you're bright and hard-working and show some initiative, you can get *something*, which will give you experience, which is what most employers want.
Yes, degrees matter (and can affect your salary), but having or not having one doesn't doom you to failure.
I wonder... sewing it at a high speed would probably break the machine, but as long as you keep everything slow, you're fine.
So technically, if you manage to hold that prison guard still while you slowly push the shiv through his armor, it'll work just fine (for you, not the guard). Interesting -- so throwing yourself on the knife might actually be a useful defense!
It reminds me of a fight scene in Dune (was that the movie? -- does anyone remember this?); they had force fields that detected and warded off quick attacks, but allowed a slow entry into the field would be allowed... so the trick to knifing someone was to do it slowly.
2. Get and keep a security clearance. Don't let it lapse. Don't do drugs or, God forbid, marry a non-U.S. citizen. Always pretend that you agree with everything George says and repeat after me: "Hanging is too good for anyone from France".
Whoops... my wife is a citizen of a country whose official religion is Islam (Malaysia), we travelled together around India a few months ago, my brother married a French citizen last year, and my little sister's in France RIGHT NOW.
I'm staying away from drugs, though -- think I might still get clearance?
...because mission control couldn't verify the correct software had been loaded.
"Excellent, Johnson; so we're all loaded and set for -- hold on, did you just say 'running on WINDOWS ME'?! Crikey, Johnson, stop that rocket! Abort! Abort!!"
Unless you're telling me they are emailing docs that both parties are adding to?!
That's a big part of my point -- you're assuming all kinds of knowledge they simply don't have until taught. It's not instinctive in any way. Why would they choose PDF over any other format available? How are they going to know the pros and cons of each? How they heck are they going to keep all of those meaningless acronyms straight? PDF, RTF, HTTP, WWW, it's all just a jumble of letters. Suppose they change over to OO, and are taught that it's possible to export into other formats... which is NOT an obvious feature. And that "PDF" is what they should use for sharing documents with other people (and that info goes on a sticky note on the monitor). Then they decide to pass the school newsletter to a friend to check it over. What do you mean, the friend can't open it? Oh, they can open it, but it doesn't go into Word, so they can't help edit it. Okay, now what?
Just think of the process, and notice how each step makes the person feel stupid. Every time they learn something new, it opens up new pitfalls.
The thing to remember about your girlfriend on Slackware, though, is that it'd be a totally different story if you weren't right there, giving her pointers. She knows you can be trusted, and so she learns the steps by rote (even using the command line isn't too hard, if you know exactly what to type), and she feels safe doing them. She's got you as a safety net, too - if something "doesn't look right" she can just ask
Most people don't have such reliable sources of help, alas. Especially not for free. The pool of people who understand enough to properly troubleshoot, etc., it still pretty small (though it's growing). It's kind of a chicken/egg problem, so it's a slow process.
This is tricky, because they need to learn more before they try OpenOffice, or they'll be turned off right away.
Before the education process, the trouble with OpenOffice is simple -- as long as they're using Word, they can save a document and most people will be able to read it.
But when they start using OpenOffice, they'll find that when they save a document now almost NO ONE can use it.
Then they see all those choices in the "save as type" dialog and say "whoa, don't want to touch that". Even saving in Word format has 3 choices. They won't know instinctively that HTML or RTF is "better" than, say, "StarWriter 3.0 Template". Both sound equally foreign (though html maybe rings a bell... but no, wait -- that probably won't work unless I start up the internet first). Let's say they crossed their fingers and went with RTF after an email from a/. reader.... Boom! Disaster strikes: "Saving in external formats may have caused information loss." Boy, that message frustrates me, because I know how most people read it (I remember switching my wife over to OO - she panicked at that dialog). They imagine whole paragraphs excised, pages gone poof. And worse -- why should they know how programs handle "files"? As far as they know, the original document (before the Save As) is also trashed now. "Information loss" is why they aren't supposed to open attachments anymore at work. Of course that looks bad.
This may all be easier a few generations from now, when the basic protocol of a computer program is taught in school and understood from an early age. For now, though, the education process is slow for most people... partly our fault, because we don't understand that new computer users are missing the basic assumptions that seem obvious to us. And also because there *are* huge pitfalls that aren't obvious. Driving a car is complicated and dangerous, but the big dangers are obvious at a basic level. Stay on the road, and don't hit other cars (or get in their way). On a computer, the catastrophes are subtle and don't feel any different from doing things right. You open an attachment from someone you know. You accidentally delete half your paper while placing the cursor and typing... then hit Save and close the word processor (recycle bin won't help you now!). Your finger presses the mouse button by accident while you're moving the mouse and drag some important system folders into another folder. Where did they go? Was that bad? Not until you reboot. You don't understand the choices on a dialog, and click the wrong button. Your DSL provider only mentioned "firewall software" somewhere in the install booklet, and you didn't know what that meant so you skipped it (my parents just got cable broadband, and I asked my Mom about this -- she'd never heard the term before).
The frustrating thing is that using a computer *could* be so much easier and safer... ah, well. What was my point here again? Oh, yeah -- education required. More than most people think.
The good thing about this company is that they're putting a lot of work and research into checking source contributions to make sure they're clean. Now they just need a business model.
The insurance thing could work, if maybe they didn't call it "insurance". Or maybe we can just get IBM and some of the other big guys coming on board to Linux to just fund them outright... and THESE guys can offer indemnification to their customers.
Then everybody benefits from the better processes, there's no black cloud of "...so Linux needs to be INSURED?", and Novell, IBM, etc. benefit because they can tout the indemnification to their customers.
Because MS can pay John Doe to contribute code from the leaked win2k source into linux and then sue every distributor of linux out of existance for copyright infringement.
That's one of the interesting things about this company -- they are actively working to prevent this. They're hiring people like PJ and doing plenty of their own research to catch John Doe before he can do any damage.
They have a massive (and growing) database of source code from free and non-free software that they can compare against newly submitted code.
All of this work takes money, of course... which is where the payments from the people they insure come in. Pretty simply business model, really -- we all want someone to do all that legwork to make sure the code is beyond reproach, but none of us individually can do it -- so they sell the service (and indemnification!) to everyone. If they do their job checking the source, they'll never have to pay out.
Seem like a win-win to me, if it works. They'll run into problems if not enough people think it's a danger.
Like really... I mean, parts of the human genome are "obvious" and therefore shouldn't be patented.... no wait...
So... if you were sued and surrendered up the rights to your family's DNA to Microsoft, would Gates get to sleep with your wife? It all just gets too complicated for words. No, wait -- I'm mixing up patents with copyright.
Slashdot Mirror
Why not just a physical (non toggle) button that enables a unit-specific password for two hours? You might have a big sticker next to the button with that machine's login info. Gain physical access to the device, and you gain access to the router. Have the machine send an e-mail out the the administrators whenever this happens. You would have to trust your employees, but if you can't trust them you are doing something very wrong.
You're making some big assumptions here, for one that "employees" are the only ones who are going to be near your routers.
Wireless access is becoming more and more pervasive -- you see routers in homes, coffeeshops, libraries, bookshops, airports, etc. etc..
Do you want to require librarians to keep a constant watch over their routers, protecting them from teenagers with paperclips?
It's not as dangerous to have a full reset button, because it's hard to do a hard reset on a router without people noticing. But a single click that enables a full admin account, with no effect on other users? No, thanks. Even the email idea is no good; the emailing functions require setup that most users don't bother with (I didn't, at least -- I don't have time for reading logs).
Sure there is. The reset button will nuke the configuration, the logs, and whatever else state is there, thus confounding debugging by the tech support. A single password is stupid, though. What's needed is something that requires the router s/n, the router's idea of the date, and a passcode generator from cisco. Give the aforementioned info to cisco TS and they can generate a 1 or 2 hour passcode for your router. You could also add a switch to enable this feature on the router itself, but that may not be practical.
I'm not convinced. This is only a concern in cases where you're having technical problems, AND you somehow forgot your password. The danger of having a backdoor easily outweighs the potential benefits. Even with a special password generator from NetGear -- you're still talking security through obscurity. I want to set up my router, make sure it's secure, and forget about it! I don't want to keep checking online to see if you can download N3tg34r_PwG3n.exe yet... and you know it's going to show up eventually.
Half the time you have any technical issues, the tech support is just going to tell you to do a hard reset anyway....
Even if they gave you one of those paperclip-hole style buttons that would reset all your passwords to your device's serial number (or to enable some other backdoor), this would still be dangerous in a lot of situations. Suppose you're running an internet cafe -- you can't always trust the people sitting around your router!
Either way, I don't think this backdoor was installed for tech support reasons -- it doesn't even seem to have been installed by NetGear themselves. Hopefully some more details will come out soon... and hopefully some heads will roll.
It's funny; I just read that new story by the AdTI guy explaining how Linux wasn't safe to use because it depended on "trust". Hah! How nice for the corporate world to step forward and show that *they* can be trusted.
that "noone" is not a word? He uses it repeatedly, so it's clearly not a typo.
Perhaps he and I can meet at Ye Olde Sandwyche Shoppe at noone to discuss this, as well as his interesting discussion of "hybrid source".
I like it how open source is dangerous because we have to have some degree of "trust" that developers aren't adding in other people's IP. Whereas private corporations developing closed source applications, with a financial incentive to steal others' IP and no easy way to get caught will be struck down by God if they do it, so we don't need to depend on "trust".
Nice.
This would be interesting on a computer, but would be fairly hard to do in print.
That was my thought too, and there are lots of examples of 3d crosswords online (try Google; for example this). If you have the wherewithal to code it yourself, or if you find a plugin you can use -- I'd say make your puzzle available online, then in the newspaper just put an intriguing screenshot and a link (tinyurl?) that readers can visit to try solving it.
Think outside the box, eh?
"Calculate When You Are Most Awake"?
That's blindingly obvious, isn't it? I mean, I do most of my calculating at about 4:30am (when the birds start singing and the sleepiness clears).
What, are most people foolishly doing their important calculations at 9am or some other such gibbering horror of an hour?
In '97-'98 I wrote a bunch of music theory training programs for the Music department at my school (they eventually became this website), and I tried out MAX first before I went with Java. MAX was far better equipped to handle the music-related requirements (anyone remember Java 1.0.2?). But with Java I could put my applets online, run them on any OS, and (biggest bonus) get some serious experience in a language that would get me my first job when I got out of college. Learning a new language to a level where you can tackle an ambitious project is a big investment. There are a lot of musicians and composers with day jobs as developers (like me) who want to be able to leverage what they already have, if feasible. And nowadays, Java has pretty good support for audio, as general-purpose languages go, so many projects wouldn't be giving up much to use Java.
Here are a few snippets from the jMusic website that suggest why they chose Java for their project:There are more hints at this in the intro of the article, as well.
I probably did exaggerate the situation a bit -- it's definitely a two-way interaction b/w MS and the hardware manufacturers. But the point still stands that it's a direct, active interaction. Some hardware manufacturers complained to MS for dropping support, some figured they could make some revenue if users were forced to upgrade to their absolute newest model... but they were all involved, and made the choice of releasing new drivers for older models, encouraging upgrades, or whatever.
You don't hear of a new Linux distro that makes huge changes to their driver model, because
a) people wouldn't switch to it without support for their older hardware, and
b) the hardware vendors wouldn't care, and wouldn't even think about putting development time into making sure their old models were supported.
I'm not an expert on this subject... but I think I have a good point here.
On the other hand, he spoke of Microsoft's support for all new hardware as if it meant that Windows was a better product, as if compatibility with new hardware was one of MS's technical achievements. This is a pretty close-minded view of the situation.
The fact is that it's primarily the new hardware which is designed and tested to be compatible with Windows , not the other way around. Can you imagine a vendor releasing a new soundcard without testing to make sure it worked on all major Windows variants? Of course not. If there are bugs in the Windows 98 drivers, the hardware vendor will work around them... even if that might mean breaking the standard interface. It's a no-brainer, considering what OS their average customer runs.
So Fred is on target with his main criticism, though he doesn't understand the chicken & egg nature of the problem. And I tend to agree with him that Linux vendors should keep prices low, partly because they can't offer quite the same experience yet, but also partly because as Linux spreads, the compatibility problem will just go away on its own. Once the hardware vendors are losing significant sales because their product can't be run on Linux, they will sit up and take note.
I'm guessing this is only available in the nightly builds for now, since I just hopped over to the site and there's no sign of a new milestone release (would be M9).
So... don't get excited -- the feature is *coded*, but you can't use it yet. That is, I haven't tried an Eclipse nightly before, but in general it's a bad idea if you're depending on the tool.
It looks like the latest integration build (a step up from a nightly) is still failing its tests.
In my experience, even some of the milestone builds have been a tad flaky (I put up with it because I want the features).
Anyone involved in the project know anything about when the next milestone release is planned?
Ah, now I see where you're coming from.
.... or it wont get collected soon enough.
Of course, a object only gets collected when it is no longer reachable. If any reference, static or not, remains reachable from the applications root objects, that object is not collected.
Right. The tricky aspect of static references that I'm trying to point out is that they're *always* reachable by those root objects, so a static reference must be explicitly nulled to free the object it refers to. This is different from normal references in object instances, which are collected along with the instance. For example -- java.awt.Color has static members white, black, etc. - each of the static references refers to an instance of the class Color. Once java.awt.Color is referenced anywhere, all of those objects will be created, and they won't be destroyed until the JVM shuts down; it doesn't matter if the instance of Color that you were using is garbage collected. See what I'm talking about? You can reference Color.white from anywhere, so it can't be collected.
So, you likely want to say that having static references might be a cause for programm errors/memory leaks?
It can be, if the coder doesn't understand what the static modifier does. I've seen code where the member variables of a class were declared static for no reason I could see, since they were accessed as if they were non-static. This caused strange errors occasionally -- when two separate instances of the class found themselves modifying the same member object (because it was static, there was only one shared by all instances). If this error were widespread, and lots of objects had these mistaken static references, then memory usage could be dramatically increased because even though the instances were GC'd, their members never could be (because they were static).
This isn't a common problem, I don't think. It just came to mind as one of the many ways your code choices will affects what the VM can do with memory.
Yes, indeed, but it is also not necessary to null away attribute references of other objects. Some people seem to think in a GC environment you have to manually null every reference to an object
Correct. Assuming all non-static references, once an object is no longer accessible, that means its members aren't accessible either, and the whole thing is eligible for collection.
I can clarify some of my points, and give examples. None of these are hard and fast rules, by the way -- it all does depend on what you're doing, and what you need. I do NOT advocate making your code unmaintainable for the sake of questionable optimizations.
... and likely thats why you claim Java si slow.
Most of the time you absolutely do not need to consider anything you preach here. First reason: all objects in Java live on the heap. So you simply can't do anything about it.
Correct, many times you *don't* need to worry about memory in Java at all, especially in client-side applications. Server-side, though, it often helps to know a little more. I'm not sure what you mean by "there's nothing you can do about" the objects on the heap... your design can have a large effect on how many objects are created, how big they are, and how long they stay on the heap. If you are processing a massive resultset from a sql query, creating a complex hierarchy of objects that each knows how to process a certain type of row, and creating one for each row, will throw a lot of objects onto the heap, and you'll get a lot more churn. If you store each one in a collection to process after you're done reading, then the garbage collector can't touch them yet, and instead of churn, your heap just grows a lot.
Static variables get collected just like non static ones.
Think about a static references to a large object. Even when all instances of class "Foo" have been GC'ed, that reference to "bigThing" remains, and bigThing is not eligible for collection, until you specifically set Foo.bigThing = null. It's not necessarily bad -- maybe there are lots of instances of Foo that all use bigThing, and you want to keep it on the heap.
Third: why does everybody repeat the myth of "carefully nulling references"? You assign null if you WANT the reference to be null, and you don't null to assist teh GC. Nulling does not assist, it only costs runtime
I'll check my post again, but I think I said that people who carefully null references are *wasting their time*. Nulling out variables *technically* does affect GC (because an object is "dead" and ready to collect when all references to it are gone), but there's usually no reason to null a local variable for this reason, because it's going out of scope in a few millisecs anyway.
Java isn't slow at all! I do most of my server-side work in Java, and it's pretty zippy and very scalable. Anyway...
This one beats it all. Sure you need a thread pool. Creating a new thread, does not only allocate a thread object, but it likely makes a kernel call to get a new thread handle. You pool to avoid the kernel call. Not to avoid the memory allocation/deallocation.
I said "probably". If you're writing a webserver or something like that, which otherwise would create scads of threads and only use them for a short time, yes. (Object pool, never -- but thread pool, sometimes). In most other applications, a thread pool is just adding complexity (especially if you write it yourself).
How long do you think it really takes to allocate a new Thread (system call, memory and all)? It's less than a millisecond; on my old laptop it's about 1/5th of a millisecond. Try it out. Even if your app creates a new Thread every 10 seconds, you're probably wasting your time with a thread pool, and you should be optimizing your SQL instead.
of course a very restricted set of applications do need to scale, but for most applications being developed by [novice coders it is] perfectly alright, because in practice the result is that memory management actually _is_ all handled for them.
Yeah, I think I clicked "Reply" with the idea of giving a few GC pointers, and ended up with a weird kind of elitist rant. I love GC, and it's totally worth the few tradeoffs (which are more education issues than anything else).
You might be minimizing the number of projects that need some level of scaleability, though. Any server-centered technology (i.e., interactive website) is based on scaling -- thin client, all the work done on the server, that sort of thing. Though I guess it comes down to this: I have seen a lot of projects coded by people who probably weren't ready for them yet... but that happens everywhere, and that's why projects have a crazy failure rate, and it isn't a problem specific to GC in any way.
Eh... I should avoid those late night posts.
While you are entirely right, this is no differnt from previous generations of programming languages
Fair enough, though if you don't understand memory management in C you will know it, because you'll have massive memory leaks or serious, noticeable bugs.
I think I mistakenly gave the impression that I don't like GC. I love it, and I think it's definitely worth the few drawbacks -- I just wanted to point out that it's not a silver bullet. And I do get frustrated with inexperienced programmers who speak scornfully of how slow Java is compared with C or C++, because their own class projects were slow...
Good article, though very limited in scope (basically just a list of GC methods, wrapping up with the methods used by recent Java and .NET interpreters). I was a little disappointed that they didn't get into the implications of using languages with GC.
One pitfall that I've noticed basically comes along with the benefit of avoiding "micro-managed" explicit memory management -- there are a lot of Java coders who don't think at *all* about memory management, because they think it's all handled for them. Mix that in with an over-excitement about OO, and you get some impressively slow and non-scaleable code.
You DO need to understand, at least on a basic level, what's going onto the heap, and what the garbage collector has to do to keep up with your "garbage". Carefully nulling out objects that are going to be out of scope in a millisecond is just wasting space, but you should definitely keep an eye on what objects you're allocating within that loop that runs a million times. They're all going on the heap; are they all going to be on there at the same time? When are they going to be eligible for collection? Are they just Strings, or larger objects (which possible create other objects when they are created)?
If you have to optimize a section of code, consider sticking to primitives and Strings (obviously you're balancing this against the cost of possibly less-maintainable code!), and don't forget that when you instantiate com.foo.Bar, all of its superclasses are also instantiated, including any member objects they hold. And don't make a variable static for no reason -- it won't get collected with the object instance....
Two useful things to think about -- heap size (the objects you're actively using at a given moment, so they can't be collected), and churn rate (how fast you're creating and trashing objects). Object creation/destruction isn't as costly as it was with the early versions of Java (no, you probably don't need that Thread pool!). But any application that needs to scale requires some thought on memory usage and churn before you start coding.
I graduated with a degree in Music composition and performance, which I very much enjoyed. I took other classes all across the board, trying to get everything I could out of college. When I graduated I got a job as a Java developer (based mostly on non-academic programming projects I did). Now I'm doing quite comfortably.
I may get an MBA a bit down the road, since it would make a nice complement to my programming experience (and what I've already learned about how business works, on the job)... but the point here is that if you're bright and hard-working and show some initiative, you can get *something*, which will give you experience, which is what most employers want.
Yes, degrees matter (and can affect your salary), but having or not having one doesn't doom you to failure.
I wonder... sewing it at a high speed would probably break the machine, but as long as you keep everything slow, you're fine.
So technically, if you manage to hold that prison guard still while you slowly push the shiv through his armor, it'll work just fine (for you, not the guard). Interesting -- so throwing yourself on the knife might actually be a useful defense!
It reminds me of a fight scene in Dune (was that the movie? -- does anyone remember this?); they had force fields that detected and warded off quick attacks, but allowed a slow entry into the field would be allowed... so the trick to knifing someone was to do it slowly.
2. Get and keep a security clearance. Don't let it lapse. Don't do drugs or, God forbid, marry a non-U.S. citizen. Always pretend that you agree with everything George says and repeat after me: "Hanging is too good for anyone from France".
Whoops... my wife is a citizen of a country whose official religion is Islam (Malaysia), we travelled together around India a few months ago, my brother married a French citizen last year, and my little sister's in France RIGHT NOW.
I'm staying away from drugs, though -- think I might still get clearance?
...because mission control couldn't verify the correct software had been loaded.
"Excellent, Johnson; so we're all loaded and set for -- hold on, did you just say 'running on WINDOWS ME'?! Crikey, Johnson, stop that rocket! Abort! Abort!!"
She will teach others, and they will teach even others, until we take over the world.
:)
Are you thinking what I'm thinking, Pinky?
Three words: Export as PDF
Unless you're telling me they are emailing docs that both parties are adding to?!
That's a big part of my point -- you're assuming all kinds of knowledge they simply don't have until taught. It's not instinctive in any way. Why would they choose PDF over any other format available? How are they going to know the pros and cons of each? How they heck are they going to keep all of those meaningless acronyms straight? PDF, RTF, HTTP, WWW, it's all just a jumble of letters. Suppose they change over to OO, and are taught that it's possible to export into other formats... which is NOT an obvious feature. And that "PDF" is what they should use for sharing documents with other people (and that info goes on a sticky note on the monitor). Then they decide to pass the school newsletter to a friend to check it over. What do you mean, the friend can't open it? Oh, they can open it, but it doesn't go into Word, so they can't help edit it. Okay, now what?
Just think of the process, and notice how each step makes the person feel stupid. Every time they learn something new, it opens up new pitfalls.
Yeah, I'm with you.
The thing to remember about your girlfriend on Slackware, though, is that it'd be a totally different story if you weren't right there, giving her pointers. She knows you can be trusted, and so she learns the steps by rote (even using the command line isn't too hard, if you know exactly what to type), and she feels safe doing them. She's got you as a safety net, too - if something "doesn't look right" she can just ask
Most people don't have such reliable sources of help, alas. Especially not for free. The pool of people who understand enough to properly troubleshoot, etc., it still pretty small (though it's growing). It's kind of a chicken/egg problem, so it's a slow process.
This is tricky, because they need to learn more before they try OpenOffice, or they'll be turned off right away.
/. reader.... Boom! Disaster strikes:
Before the education process, the trouble with OpenOffice is simple -- as long as they're using Word, they can save a document and most people will be able to read it.
But when they start using OpenOffice, they'll find that when they save a document now almost NO ONE can use it.
Then they see all those choices in the "save as type" dialog and say "whoa, don't want to touch that". Even saving in Word format has 3 choices. They won't know instinctively that HTML or RTF is "better" than, say, "StarWriter 3.0 Template". Both sound equally foreign (though html maybe rings a bell... but no, wait -- that probably won't work unless I start up the internet first). Let's say they crossed their fingers and went with RTF after an email from a
"Saving in external formats may have caused information loss." Boy, that message frustrates me, because I know how most people read it (I remember switching my wife over to OO - she panicked at that dialog). They imagine whole paragraphs excised, pages gone poof. And worse -- why should they know how programs handle "files"? As far as they know, the original document (before the Save As) is also trashed now. "Information loss" is why they aren't supposed to open attachments anymore at work. Of course that looks bad.
This may all be easier a few generations from now, when the basic protocol of a computer program is taught in school and understood from an early age. For now, though, the education process is slow for most people... partly our fault, because we don't understand that new computer users are missing the basic assumptions that seem obvious to us. And also because there *are* huge pitfalls that aren't obvious. Driving a car is complicated and dangerous, but the big dangers are obvious at a basic level. Stay on the road, and don't hit other cars (or get in their way). On a computer, the catastrophes are subtle and don't feel any different from doing things right. You open an attachment from someone you know. You accidentally delete half your paper while placing the cursor and typing... then hit Save and close the word processor (recycle bin won't help you now!). Your finger presses the mouse button by accident while you're moving the mouse and drag some important system folders into another folder. Where did they go? Was that bad? Not until you reboot. You don't understand the choices on a dialog, and click the wrong button. Your DSL provider only mentioned "firewall software" somewhere in the install booklet, and you didn't know what that meant so you skipped it (my parents just got cable broadband, and I asked my Mom about this -- she'd never heard the term before).
The frustrating thing is that using a computer *could* be so much easier and safer... ah, well. What was my point here again? Oh, yeah -- education required. More than most people think.
The good thing about this company is that they're putting a lot of work and research into checking source contributions to make sure they're clean. Now they just need a business model.
The insurance thing could work, if maybe they didn't call it "insurance". Or maybe we can just get IBM and some of the other big guys coming on board to Linux to just fund them outright... and THESE guys can offer indemnification to their customers.
Then everybody benefits from the better processes, there's no black cloud of "...so Linux needs to be INSURED?", and Novell, IBM, etc. benefit because they can tout the indemnification to their customers.
Because MS can pay John Doe to contribute code from the leaked win2k source into linux and then sue every distributor of linux out of existance for copyright infringement.
That's one of the interesting things about this company -- they are actively working to prevent this. They're hiring people like PJ and doing plenty of their own research to catch John Doe before he can do any damage.
They have a massive (and growing) database of source code from free and non-free software that they can compare against newly submitted code.
All of this work takes money, of course... which is where the payments from the people they insure come in. Pretty simply business model, really -- we all want someone to do all that legwork to make sure the code is beyond reproach, but none of us individually can do it -- so they sell the service (and indemnification!) to everyone. If they do their job checking the source, they'll never have to pay out.
Seem like a win-win to me, if it works. They'll run into problems if not enough people think it's a danger.
Like really... I mean, parts of the human genome are "obvious" and therefore shouldn't be patented.... no wait...
So... if you were sued and surrendered up the rights to your family's DNA to Microsoft, would Gates get to sleep with your wife? It all just gets too complicated for words. No, wait -- I'm mixing up patents with copyright.