Many years ago, I ran a site called Half-Empty. It was an exciting time, I was in college, and had hacked together this site (letting my grades suffer in the process) as a way for people to share stories and vote on them. It was kind of like a ghetto version of Digg, where the users posted content not links.
One of the biggest thrills for me ever was when I sent an e-mail to/. about its initial launch and made it onto the front page. My dorm room was Slashdotted, I pulled RAM out of my roommates computers and threw it into my little server, which somehow survived. I knew it was inevitable my cable connection would be cut off so I sent an SOS out for anyone who would be willing to host the site for free, I was a poor college student, and Krellis from DynDNS stepped in. Half-Empty grew for a few years and became a large part of my life and many others. I owe the experience entirely to that initial Slashdotting, which gave the site the momentum it needed to stay alive. I regret not keeping the site up; it was a victim of a hard drive crash and I was enough of an amateur at the time to not have been making regular backups.
So, thanks again Rob. Good luck, and be proud of all you've accomplished with Slashdot. Cheers!
My T500's wifi doesn't work in Ubuntu if I want to use the latest server kernel with 4GB RAM. I had no patience so I just bought a pcmcia card (time is money) -- YMMV.
This generally isn't true. A VC will get preferred stock and as such in a liquidation event they will be able to recover their money before anyone else can. (So if you take on 1M in funding, sell the company for 500K, you're right, you get nothing and they lose 500K). I'm guessing this is what you're thinking of.
If you sell the company for 2M and they put in 1M, they get their 1M back and the rest of the pie can be sliced up in different ways depending on the term sheet. (Google participating preferred stock cap)
It's apples and oranges. Tassl is a Facebook application that has a fluid UI for navigating courses and using the social network. It's not really a LMS.
I am building a student-driven Facebook app called Tassl. It does not have user roles, so it is probably safe from this patent. It indexes course data from about 100 universities now and allows you to post assignments and exams in your course via your Facebook account. It also has a News Feed that keeps you up to date when stuff is coming up that is due. Check it out. Does anyone think I am screwed here?
Probably beating a dead horse, but there are two problems with this approach.
First, less importantly, it goes against OOP principals to create these stub classes like you're talking about. I've never seen this technique espoused by anyone in any OOP text or anywhere for that matter UNLESS it is a means of making a counterpoint against Hungarian. Would you actually ever do this? Fundamentally, if the class does not include different behavior than its base (different methods or overrides) then it does not warrant a new class, period.
Second, and more importantly, again types are addressing a different problem than Hungarian. (Apps) Hungarian is simply a style of naming, that is it. Unless you name your variables using a random string generator, you have two choices when you name variables. Either you do a free for all naming style or name it in a systematic way that maximizes the expression of your intent by reusing concepts that are expressed in other parts of the code. The latter is obviously a smarter approach, and Hungarian is designed to be the logical finality of taking this approach to its limits.
For example, prefixing an int variable with a c indicates it is a count of things (as opposed to a max value, an index into something, a min value, a limit value, etc.) Extend this concept to classes and you can understand my example above better. Hint: in a B+ tree, a Page object is sometimes treated as a root but during a split it is treated as a leaf. The underlying type of the object doesn't change and there is nothing particularly special about roots or leaves (as your class example suggests) other than their role in an algorithm.
So, you have a choice -- do we name our local page objects root, leaf, rootPage, leafPage, etc (or pull some other names out of our ass) or do we do something precise and consistent with the rest of our code. Hungarian calls for you to prefix it so that we can look it up in a Hungarian table we will soon have memorized after working on the project. Conventions are powerful things, and (apps) hungarian is just a set of conventions to guide naming to augment the ad hoc almost all programmers currently do now.
Well, I think you might be misunderstanding my examples. Types and hungarian are solving two different problems. Say for example we are building a relational database system. I remember when I worked on one in college we had a Page object. Now, the Page object was a page of data on disk and had a universal set of operations and data making it a clear case for an object. However, code doing merge sorts, buffer management, etc, all used various Page objects. There is no point in creating a new class for each of the dozens of use cases for Page objects, since the cases themselves don't warrant new methods or data in the Page itself. The algorithms for manipulating pages were well factored and placed in external classes, but you still have a lot to say about the specific Pages in use within the algorithms themselves.
So, it is useful to the programmer and others to name Page variables in a consistent way depending on how they are being *used*. For example this Page is a leaf page of a B+ Tree, we prefix it w "btl", if its the root we prefix it with "btr". So if we have a old tree and a new tree, we might have btrOld and btrNew. Once someone knows the conventions, all the B+ tree code will just make perfect sense since they will just 'know' that "btrOld" is the root B+ tree page of the old tree. You might find dozens of these canonical usages throughout many, many lines of source code. Instead of having to come up with unique names which end up actually obfuscating your intention to outsiders (and as time goes by, to yourself,) by coming to a consensus on a small set of Hungarian conventions and patterns, the intentions and clarity of the code is magnified greatly.
As someone who has worked on large projects both with and without Hungarian notation I can confidently say that this above type of use case comes up very often. In fact, I would argue that it is much cleaner to use Hungarian notation instead of polluting your namespace with new classes just to encode this intentional metadata about variables. (Since really, according to OOP principals, they should not be different types since they do not have different methods or data.)
Also, to address your argument about the most effective tools to be those that can be checked by a computer, I urge you to check out all the cool stuff going on with Ruby. Static type checking has it's pro's, but the con's become clear once you toy with a language that trusts the programmer a bit to keep track of types (and if you're using Hungarian, intentions.)
Actually there are many cases where you want to describe your intention in using a certain variable that doesn't warrant a new data type. For (a simple) example, an input or output buffer. You need two buffers, no need to declare two different types, but one is for input and one is for output. By describing your intentions of the input vs output in a clear and consistent way throughout your code, you make it much more likely you will visually catch errors. Additionally, new programmers will understand your intentions much more clearly when reading your code (once they learn the notation.)
Again, the key thing to distinguish here is that you are not using different types of objects, but are using the same object for different reasons. I'm sure it doesn't take much effort to think of scenarios where you have no need to declare a subclass for something but clearly are using an instance of a class for a specific, describable purpose that would be useful to describe in the code itself.
You can do a lot of useful tricks with reflection when its mixed in with code generation, for what it's worth. Ie, dynamically build a custom class on the fly, compile it on the fly, and then instantiate it on the fly.
For example, the persistence framework we use actually generates proxy classes on the fly that handle transaction management, etc. Hooking into these things (and determining how to build them) requires some advanced reflective techniques.
I'll put a cheap plug here, since it's awesome: www.x-tensive.com
Another thing we use it for is to dynamically build and hook into older versions of our libraries for building SQL migration scripts. For example, our tool will revert source back to the previous revision, build the stuff, dynamically instantate the class, save the database schema required, roll it forward, build, repeat, and find the "SQL diff" of the two databases which we then tweak for migration purposes. Doing this elegantly and cleanly would not be possible without reflective techniques.
I haven't posted on/. in like a year, but just wanted to note that everyone should read the above comment, as it actually analyzes the situation objectively and doesn't just make broad assumptions about the intentions of either side, like all the other comments here.
My professor, Dr. Steve Marschner, won one of the awards (with some colleagues) for his work on subsurface scattering. Its a shame they weren't mentioned in the article:(
I don't think that's right. If I download 10 bytes from a machine, that machine uploads 10 bytes to me. Hence the terms upload bandwidth and download bandwidth.
What the default enabled services have to do with the windows security model is beyond me. Windows is not fundamentally insecure, as I said, it's default installation parameters may put it into a state which sacrifices convenience (people actually USE a lot of those services) for potential attack, as you said, but that doesn't mean there is some inherent flaw in the way windows operates (lacking in linux) that somehow makes it more exploitable.
The best point you make is that if disabling RPC screws up local stuff then that's bad, but I haven't verified that myself.
People here would have you believe that if you opened up all your ports on Linux and the same ports on Windows and exposed Linux to 90% of the world it would somehow avoid being ravaged by viruses as Windows is because it's superior in some mystical, undefinable sense.
I fail to see how issues like this show that windows is fundamentally insecure.
- The patch came out a month ago. - They have 90% of the marketshare, so one would assume that 90% of the viruses created are written to target exploits on Windows. - They have 90% of the marketshare, so one would assume that people who spend their time looking for security holes will spend 90% looking at Windows.
If Linux had 90% marketshare and was used mostly by people who don't patch, like Windows is, I fail to see how architectually Linux would be more immune to this type of attack than Windows is. The reason this doesn't happen with Linux is not because it's oh so superior to Windows software wise but because it's used by less people (less rate of infection, less motivation for hackers to write viruses), and the people who use it are competent enough with computers to make sure their stuff is patched and healthy.
The people who run Linux at home or in the office didn't get this virus because their Windows machines were patched. Why do you think that is?
Maybe if the editors didn't spam the fucking article with 10,000 links I could have actually found an article. The only thing I saw of relevance was the link to the actualy C&D letter.
You are a beacon of logic in a sea of idiocy. My intellectual bowels have been temporarily cleansed, though I can already smell the shit brewing in the comments above and below yours and in the inevitable replies to come.
God knows we can't blame the guys for wanting to get on their soapbox, publicize the information, and in exchange for a raging geek hardon let every college kid using this system now exploit the fuck out of it until Bb can get it fixed.
Of course, the/. geeks will insist that somehow keeping this from being publicized in an open public forum will somehow magically cause more exploits. Assuming, as always, that the company has no interest in fixing the bug ASAP because they are too lazy or incompetent. (Unlike our open source Linux heros!)
These leet dudes could never have just quietly told Blackboard about the bug in advance and given them a deadline to fix it by before they go public. I mean, where's the fame and glory (and the link on Slashdot!) in that???
Could it be perhaps, that Bb wants to minimize the damage of this exploit by keeping it quiet while they create a patch? Nah, all corporations are evil and are full of incompetent programmers and managers who are somehow able to get people to pay for shitty software. Every company is like Microsoft, right?
Relying on the vast research done in optimizing and implementing the relational model for performing complicated searches is not stupid, it's damn smart.
It's the same reason you don't write assembly OR hand optimize your high level code. Let the compiler do its job, and let the RDBMS do it's job.
You're arrogant and/or naive to assume that a simple text search is what he's referring to. What if you want to perform the eqivalent of a left outer join and a few inner joins combined with a UNION, INTERSECT, and NOT EXIST clause here or there? Good fucking luck, coding master.
Don't let the idiots get you all bent out of shape. There have always been people without vision and who cannot see the forest from the trees. The "intellectual" ones always cause the most damage, unfortunately.
There are popular nerds. There are unpopular nerds. The nerds which are unpopular are condescending, arrogant, assholes who measure their self-worth by how many Linux distros they've installed and what other people say about them. The popular nerds understand that different people have different talents and flaws, and are able to be social due to their high self-esteem and lack of worry about what others think of them.
Slashdot Mirror
Many years ago, I ran a site called Half-Empty. It was an exciting time, I was in college, and had hacked together this site (letting my grades suffer in the process) as a way for people to share stories and vote on them. It was kind of like a ghetto version of Digg, where the users posted content not links.
One of the biggest thrills for me ever was when I sent an e-mail to /. about its initial launch and made it onto the front page. My dorm room was Slashdotted, I pulled RAM out of my roommates computers and threw it into my little server, which somehow survived. I knew it was inevitable my cable connection would be cut off so I sent an SOS out for anyone who would be willing to host the site for free, I was a poor college student, and Krellis from DynDNS stepped in. Half-Empty grew for a few years and became a large part of my life and many others. I owe the experience entirely to that initial Slashdotting, which gave the site the momentum it needed to stay alive. I regret not keeping the site up; it was a victim of a hard drive crash and I was enough of an amateur at the time to not have been making regular backups.
So, thanks again Rob. Good luck, and be proud of all you've accomplished with Slashdot. Cheers!
My T500's wifi doesn't work in Ubuntu if I want to use the latest server kernel with 4GB RAM. I had no patience so I just bought a pcmcia card (time is money) -- YMMV.
This generally isn't true. A VC will get preferred stock and as such in a liquidation event they will be able to recover their money before anyone else can. (So if you take on 1M in funding, sell the company for 500K, you're right, you get nothing and they lose 500K). I'm guessing this is what you're thinking of.
If you sell the company for 2M and they put in 1M, they get their 1M back and the rest of the pie can be sliced up in different ways depending on the term sheet. (Google participating preferred stock cap)
It's apples and oranges. Tassl is a Facebook application that has a fluid UI for navigating courses and using the social network. It's not really a LMS.
I am building a student-driven Facebook app called Tassl. It does not have user roles, so it is probably safe from this patent. It indexes course data from about 100 universities now and allows you to post assignments and exams in your course via your Facebook account. It also has a News Feed that keeps you up to date when stuff is coming up that is due. Check it out. Does anyone think I am screwed here?
Probably beating a dead horse, but there are two problems with this approach.
First, less importantly, it goes against OOP principals to create these stub classes like you're talking about. I've never seen this technique espoused by anyone in any OOP text or anywhere for that matter UNLESS it is a means of making a counterpoint against Hungarian. Would you actually ever do this? Fundamentally, if the class does not include different behavior than its base (different methods or overrides) then it does not warrant a new class, period.
Second, and more importantly, again types are addressing a different problem than Hungarian. (Apps) Hungarian is simply a style of naming, that is it. Unless you name your variables using a random string generator, you have two choices when you name variables. Either you do a free for all naming style or name it in a systematic way that maximizes the expression of your intent by reusing concepts that are expressed in other parts of the code. The latter is obviously a smarter approach, and Hungarian is designed to be the logical finality of taking this approach to its limits.
For example, prefixing an int variable with a c indicates it is a count of things (as opposed to a max value, an index into something, a min value, a limit value, etc.) Extend this concept to classes and you can understand my example above better. Hint: in a B+ tree, a Page object is sometimes treated as a root but during a split it is treated as a leaf. The underlying type of the object doesn't change and there is nothing particularly special about roots or leaves (as your class example suggests) other than their role in an algorithm.
So, you have a choice -- do we name our local page objects root, leaf, rootPage, leafPage, etc (or pull some other names out of our ass) or do we do something precise and consistent with the rest of our code. Hungarian calls for you to prefix it so that we can look it up in a Hungarian table we will soon have memorized after working on the project. Conventions are powerful things, and (apps) hungarian is just a set of conventions to guide naming to augment the ad hoc almost all programmers currently do now.
Well, I think you might be misunderstanding my examples. Types and hungarian are solving two different problems. Say for example we are building a relational database system. I remember when I worked on one in college we had a Page object. Now, the Page object was a page of data on disk and had a universal set of operations and data making it a clear case for an object. However, code doing merge sorts, buffer management, etc, all used various Page objects. There is no point in creating a new class for each of the dozens of use cases for Page objects, since the cases themselves don't warrant new methods or data in the Page itself. The algorithms for manipulating pages were well factored and placed in external classes, but you still have a lot to say about the specific Pages in use within the algorithms themselves.
So, it is useful to the programmer and others to name Page variables in a consistent way depending on how they are being *used*. For example this Page is a leaf page of a B+ Tree, we prefix it w "btl", if its the root we prefix it with "btr". So if we have a old tree and a new tree, we might have btrOld and btrNew. Once someone knows the conventions, all the B+ tree code will just make perfect sense since they will just 'know' that "btrOld" is the root B+ tree page of the old tree. You might find dozens of these canonical usages throughout many, many lines of source code. Instead of having to come up with unique names which end up actually obfuscating your intention to outsiders (and as time goes by, to yourself,) by coming to a consensus on a small set of Hungarian conventions and patterns, the intentions and clarity of the code is magnified greatly.
As someone who has worked on large projects both with and without Hungarian notation I can confidently say that this above type of use case comes up very often. In fact, I would argue that it is much cleaner to use Hungarian notation instead of polluting your namespace with new classes just to encode this intentional metadata about variables. (Since really, according to OOP principals, they should not be different types since they do not have different methods or data.)
Also, to address your argument about the most effective tools to be those that can be checked by a computer, I urge you to check out all the cool stuff going on with Ruby. Static type checking has it's pro's, but the con's become clear once you toy with a language that trusts the programmer a bit to keep track of types (and if you're using Hungarian, intentions.)
Actually there are many cases where you want to describe your intention in using a certain variable that doesn't warrant a new data type. For (a simple) example, an input or output buffer. You need two buffers, no need to declare two different types, but one is for input and one is for output. By describing your intentions of the input vs output in a clear and consistent way throughout your code, you make it much more likely you will visually catch errors. Additionally, new programmers will understand your intentions much more clearly when reading your code (once they learn the notation.)
Again, the key thing to distinguish here is that you are not using different types of objects, but are using the same object for different reasons. I'm sure it doesn't take much effort to think of scenarios where you have no need to declare a subclass for something but clearly are using an instance of a class for a specific, describable purpose that would be useful to describe in the code itself.
You can do a lot of useful tricks with reflection when its mixed in with code generation, for what it's worth. Ie, dynamically build a custom class on the fly, compile it on the fly, and then instantiate it on the fly.
For example, the persistence framework we use actually generates proxy classes on the fly that handle transaction management, etc. Hooking into these things (and determining how to build them) requires some advanced reflective techniques.
I'll put a cheap plug here, since it's awesome: www.x-tensive.com
Another thing we use it for is to dynamically build and hook into older versions of our libraries for building SQL migration scripts. For example, our tool will revert source back to the previous revision, build the stuff, dynamically instantate the class, save the database schema required, roll it forward, build, repeat, and find the "SQL diff" of the two databases which we then tweak for migration purposes. Doing this elegantly and cleanly would not be possible without reflective techniques.
I haven't posted on /. in like a year, but just wanted to note that everyone should read the above comment, as it actually analyzes the situation objectively and doesn't just make broad assumptions about the intentions of either side, like all the other comments here.
My professor, Dr. Steve Marschner, won one of the awards (with some colleagues) for his work on subsurface scattering. Its a shame they weren't mentioned in the article :(
Or maybe you're both right, he doesn't want to waste his life spending most of it playing video games, and therefore, sucks at them.
SHOCKING!
I don't think that's right. If I download 10 bytes from a machine, that machine uploads 10 bytes to me. Hence the terms upload bandwidth and download bandwidth.
What the default enabled services have to do with the windows security model is beyond me. Windows is not fundamentally insecure, as I said, it's default installation parameters may put it into a state which sacrifices convenience (people actually USE a lot of those services) for potential attack, as you said, but that doesn't mean there is some inherent flaw in the way windows operates (lacking in linux) that somehow makes it more exploitable.
The best point you make is that if disabling RPC screws up local stuff then that's bad, but I haven't verified that myself.
People here would have you believe that if you opened up all your ports on Linux and the same ports on Windows and exposed Linux to 90% of the world it would somehow avoid being ravaged by viruses as Windows is because it's superior in some mystical, undefinable sense.
I fail to see how issues like this show that windows is fundamentally insecure.
- The patch came out a month ago.
- They have 90% of the marketshare, so one would assume that 90% of the viruses created are written to target exploits on Windows.
- They have 90% of the marketshare, so one would assume that people who spend their time looking for security holes will spend 90% looking at Windows.
If Linux had 90% marketshare and was used mostly by people who don't patch, like Windows is, I fail to see how architectually Linux would be more immune to this type of attack than Windows is. The reason this doesn't happen with Linux is not because it's oh so superior to Windows software wise but because it's used by less people (less rate of infection, less motivation for hackers to write viruses), and the people who use it are competent enough with computers to make sure their stuff is patched and healthy.
The people who run Linux at home or in the office didn't get this virus because their Windows machines were patched. Why do you think that is?
So perhaps the world isn't round or the heart isn't a pump?
Sounds like somebody's got a case of the Mondays!
Maybe if the editors didn't spam the fucking article with 10,000 links I could have actually found an article. The only thing I saw of relevance was the link to the actualy C&D letter.
P.S. I still don't see it.
You are a beacon of logic in a sea of idiocy. My intellectual bowels have been temporarily cleansed, though I can already smell the shit brewing in the comments above and below yours and in the inevitable replies to come.
God knows we can't blame the guys for wanting to get on their soapbox, publicize the information, and in exchange for a raging geek hardon let every college kid using this system now exploit the fuck out of it until Bb can get it fixed.
/. geeks will insist that somehow keeping this from being publicized in an open public forum will somehow magically cause more exploits. Assuming, as always, that the company has no interest in fixing the bug ASAP because they are too lazy or incompetent. (Unlike our open source Linux heros!)
Of course, the
These leet dudes could never have just quietly told Blackboard about the bug in advance and given them a deadline to fix it by before they go public. I mean, where's the fame and glory (and the link on Slashdot!) in that???
Could it be perhaps, that Bb wants to minimize the damage of this exploit by keeping it quiet while they create a patch? Nah, all corporations are evil and are full of incompetent programmers and managers who are somehow able to get people to pay for shitty software. Every company is like Microsoft, right?
Does it mean that 99% of its use will be for illegal activities? Almost certainly.
IntelliJ has high level Java-specific features that I'm sure the Eclipse team has not even begun considering implementing. It wins hands down.
Relying on the vast research done in optimizing and implementing the relational model for performing complicated searches is not stupid, it's damn smart.
It's the same reason you don't write assembly OR hand optimize your high level code. Let the compiler do its job, and let the RDBMS do it's job.
You're arrogant and/or naive to assume that a simple text search is what he's referring to. What if you want to perform the eqivalent of a left outer join and a few inner joins combined with a UNION, INTERSECT, and NOT EXIST clause here or there? Good fucking luck, coding master.
Don't let the idiots get you all bent out of shape. There have always been people without vision and who cannot see the forest from the trees. The "intellectual" ones always cause the most damage, unfortunately.
There are popular nerds. There are unpopular nerds. The nerds which are unpopular are condescending, arrogant, assholes who measure their self-worth by how many Linux distros they've installed and what other people say about them. The popular nerds understand that different people have different talents and flaws, and are able to be social due to their high self-esteem and lack of worry about what others think of them.