I think that a company should be able to control distribution channels of their content in electronic format. Where I believe I differ from most in the mechanism to achieve the control. They (the industry (purposely vague reference)) have chosen to invest $$$ in lawyers and lobbyists to create laws like the DMCA. When they believe somebody has stolen service, they pay more $$$ to more lawyers to prosecute. And then we (the defendants) pay $$$ for our own lawyers. And we go to court, which lots of times takes months. Bah! Net result: lots of $$$ spent, lawyers getting most of it. And what happens if somebody outside US jurisdiction violates the law? Is DTV going to travel to Afghanistan to hunt down Ahkmed Ahkmed Jallalbad for getting his "The Hot Network" fix? No. So the laws work great inside the US but don't work outside our borders. That's a winning strategy in an increasingly global economy!
My alternative is to take all the $$$ that would be spent on lawyers, beurocrats, and lobbyists, and... improve the technology. If DTV took all of the loot it spent prosecuting people and lobbying, I believe they could create a virtually uncrackable platform. Let's get PKI to be almost a household term. Let's get thumbprint identification on the remote controls of our satellite boxes that can authenticate our service. What's the net result with this approach? Fewer court cases, technology that can be exported beyond US borders, less government bullshit, and a happier more secure piece of equipment.
I don't know why more people don't see it this way....
Yes I mind that you eavesdrop on my cell phone conversation. Should you have a right to? In my opinion yes. If the cellular telephone company makes the decision to *not* encrypt their channels, or if they do a piss poor job at encrypting their channels, then I would *expect* my conversation to be hacked.
In my opinion, the DTV signal argument postulated by AgentTim3 is similar to the telnet vs ssh debate. Let's say that you are a company that provides Unix shell accounts to people. In exchange for $$$, you offer service to a Unix account. If you provide telnet access, and somebody snoops the packets, steals a username and password, and breaks into your account - have they broken a law? Sadly yes (the DMCA).
Fact is the company should have used ssh as an interaction mechanism. Similarly, if somebody out there receives DTV's signal and decodes it, are they any more guilty than the guy who packet sniffed?
Unfortunately, both situations above are considered illegal. In my opinion this is another case of government attempting to regulate stupidity. If "Shells 'R Us" is dumb enough to offer telnet access, and consumers are dumb enough to use it, they deserve the repurcussions of having someone tear them a new one. Likewise, if DTV doesn't make the investment in equipment and software to stay ahead of the hacking community, then they deserve the diminished revenue they receive.
While you certainly received a solid cornerstone of XP (keeping inventory low), there are other aspects of the methodology that are easy to implement, and produce magnitudes of fruit. I'm afraid you might not have fully absorbed the XP message: communication, simplicity, and testing are the key tennants (imo of course).
A lot of people fall into the trap of relating the XP methodology to some familiar aspect of their current methodology. For example, a lot of my coworkers associate "stories" with "use cases" or "requirements". While use cases and requirements documents represent a subset of what a story represent, they fail to convey the communication and interaction with the customer essential to success. Moreover, stories are vehicles through which intent is transmitted between the customer and the programmer. I haven't been on a project yet where the customer wrote a use case, programmers disected it into small parts, estimated the effort required, handed it back to the customer, and asked the customer to define which use cases were the most important. More often than not, the customer does not even write the use cases, much less define which ones are to be implemented first. Often the programmers (or some manager associated with the development effort) write the use cases. And a lot of times, acceptance tests are not written to confirm the implementation of the use case. These concepts are all tangents around the XP methodology involving stories. Simply put, use cases are NOT the same as stories. XP Stories involve interaction, are estimated for time, are specified by the customer, are prioritized by the customer, and are verified by tests written by the customer. Use cases are just procedures.
Do you actually have a point or do you just enjoy rambling?
BTW, here's a fact - Frank Rhines (sp?) is the CEO of Fannie Mae, a company with so much annual revenue that they actually have a "trillion dollar day" (the day where they actually earned their trillionth dollar of revenue). Their revenue exceeds the GDP of all other countries in the world (except a small handful like Germany or England). Oh ya, and did I mention that he's black?
What's funny is that there were talks a year or so ago by the NAACP (or some other organzation) about Fannie Mae hiring too many "White Male" employees. Frank came out and said "hello, umm... I'm black. Why would I do that???" Momentum suddenly dwindled.
Get your facts straight, pull some examples, and make a point instead of rambling.
What is fascinating to me is the amount of effort people put into cooling their system to achieve a couple of hundred more mhz of power. I understand that it's more of a hobby than anything else - it's not like the owners are running nuclear detonation scenarios and the +100mhz allows them to finish their work 1 month sooner. And I respect that - I've hacked my TiVO and my SonicBlue audio receiver 'because I could'.
But what is pretty funny is that in 1 year, a 3.3ghz chip will be for sale out of the box. It must be kinda frustrating (maybe?) to put all this work into vapochilling your processor, installing a water-based cooling system, drilling blow-holes in the case, etc to achieve a N + M mhz processor (N is what the processor should run at, M is how much overclocking has been achieved) when an N + M mhz processor will come out in a year.
I suppose what's more remarkable is that the processor makers are able to produce faster and faster chips so quickly.
Your point is well taken. Simply opening a file format does *not* change anything. If MS is truly interested in interoperability with third party developers / scripters, they will make a concerted effort to document their XML as well as keep it consistent.
For example...
I work on an xml driven middleware project. We have gone to great lengths (via xsl scripts) to generate documentation that matches our dtds. We really focus on backwards compatibility and not breaking it, so as to happily interoperate with the community (specifically with older clients). If MS wants to continue to protect it's market position, they could *quite* easily "use xml" as their file format but obfuscate (via a volatile dtd) it enough that it becomes such a moving target that nobody *wants* to use it. Consider a bogus specification that states that the namespaces, element names, and overall structure completely change (unpredictably) if you have a regularly faced document vs a bold faced document.
What's my point? Don't assume that MS is opening their file format because they are using xml. It's a clever ploy on their part to say to the world (and more importantly to the DoJ) - 'look, we're inter-operating with the world because we use xml', but then not publish a DTD, not document, break backwards compatibility with every patch release, etc etc etc... In the end the only components interacting are the MS Word application and the MS Word'ed XML docs on your filesystem.
Indeed. An often-times overlooked benefit of open-source is the exposure a product can attain simply by virtue of being open. A closed source product team has to make an investment in a quality assurance group, which usually works 9 - 5. An open source project (assuming it is highly visible) is capable of leveraging a global supply of quality assurance engineers to test their product 24 hours a day, 7 days a week. The whole world is essentially their beta testers.
While the Samba folks have done us Linux folk a tremendous favor (reverse engineering *any* protocol is difficult) in encapsulating all of the SMB details via Samba, they have also performed a huge service to MicroSoft and the rest of the closed-source world by hammering on the various platforms that come out of Redmond. As the article points out, every new version (or patch release) is put through it's paces against Samba. Although their primary goal is to ensure compatibility, the secondary effect is extremely valuable to non-Samba users: bugs in server software from a closed source vendor are exposed (and hopefully fixed).
The difficulty is that the rest of the world (and probably MicroSoft in particular), either doesn't see, or see's but turns a cold shoulder none-the-less to the open source community.
Thank you Andrew for your work and the work of your team.
How about the plumbing? In the US, most homes come with a 3/4 inch aluminum pipe from the street to feed water. Are they the same where you live? Usually, the location that the pipe enters the house is underground and in a utility room or furnace room. You could use that room to drill another 3/4 inch pipe parallel to the water pipe out to the central sewer / water tunnel.
In the furnace room of each house, install an access point. Generally, 2.4ghz bounces off of concrete (but has a tough time going through it). Once you get the signal inside the house, it shouldn't be hard to get it from the basement to the attic.
It sounds to me that the jump between houses is the hard part. Solve that and you've got your problem licked. Perhaps the sewer system will work...
The ring lasted for about a year before the amethyst point worked its way loose. I Krazy-glued it in and it stayed in for a few weeks more before I lost it for good.
From the article: This article imagines a "Java 3" that jettisons the baggage of the last decade, and proposes numerous changes to the core language, virtual machine, and class libraries. The focus here is on those changes that many people (including the Java developers at Sun) would really like to make, but can't -- primarily for reasons of backwards compatibility.
In other words, Elliotte fully understands *why* his proposed changes would be difficult to implement. His 10 changes are contingent upon the assumption that you can break backwards compatibility.
It doesn't seem totally unreasonable to me. Microsoft forces people to upgrade their OS in order to support newer versions of their Office product. While I'm definitely not a Microsoft advocate, I believe that forced upgrades aren't necessarily a "bad thing."
Assuming Java 3.0 were implemented and backward compatibility was broken, Sun wouldn't pull the downloads for Java 2.0 off their websites. Moreover, a magical wave of energy won't wash over the planet halt'ing all Java 2.0 and 1.0 applications and permanently erasing their JDK installations. The 2.0 and 1.0 Java applications would simply become "legacy" code until such time that they are either replaced or updated to the new Java 3.0. In fact, it would not surprise me if a significant number of the apps were not migrated (because they were not judged important enough to spend money to upgrade) and continued to execute under the old Java.
The authors of Java 1.0 and Java 2.0 applications didn't have the benefit of coding under the "3.0 conventions". If the applications they wrote could really benefit from the changes, the authors will go back and refactor. If not, the application will continue to run in it's current form for years to come.
Upgrades are like refactorings. While toothless ones are trivial, they rarely provide significant benefit. It's usually the difficult upgrades (EJB 1.1 to 2.0?) that provide real opportunity for advancement. The 10 proposals by Elliotte seem like an example of the latter.
There was nothing in the article about the technical progress of Linux. It was all external uses of Linux. Interesting to some people. But I wanted to see stuff like: May 13, 1994: Donald Becker (becker@cesdis) writes the first 3Com driver.
Those are the tear-jerking memories that I wanna read about!
Things to *not* do:
- abbreviate variables
- define all your variables at the top of a method
- document how the method is doing what it does
Why *not*?
- abbreviate variables.
This enables naming collisions. For example: AddressInformation ai and AssertionInclude ai. If a maintainer has recently been in the assertion portion of the application logic, and is dropped into the user component (and comes across ai), they may make a mistake
- define your variables at the top of the method
Defining (and instantiating) variables only before the blocks of code where they are required adds extra meta-information to those variables. Blindly defining them at the top can lead to situations where blocks of code are removed from a method, but variables are not removed because they are defined and instantiated many lines above the block of code that was removed.
- define how the method is doing what it does
A comment of "iterates over the array specified, and performs a binary search of the class member foo, checking for equality with any of the elements" is meaningless to me at an API level. "compares the provided array with the internal state returning true if they are equal" is much more meaningful
Lots of luck to you on this. On my project it's really hard to get people to write good documentation. I don't know C++ very well at all, but a useful exercise for us Java programming folks (and maybe there is some analogy in the C++ realm that I'm not aware of) is looking at JavaDoc's first. If you are on a project with 500+ classes and you need to use an instance of some other class in the system, pull up it's JavaDoc information. Don't pull up the source. When you pull up the source, you tend to look at the actual code to figure out what the method does. If you look at the API you are evaluating the quality of the documentation. This leads to better documentation (because people realize the current documentation is inadequate) as well as a better developer knowledge. Treat your own internal API as an external library (like xerces). See how well the two stand up in terms of clarity and ambiguity. It's certainly the best lesson I've learned...
Even given the arguments against going to college, I would still go for the experience. I've seen countless folks who've not gone to college (that I now work with!) who are paid well, but do not possess the "got to get this working no matter what" attitude that one gets while attending a formal college. Those co-workers are the 9-5'ers who call it quits at 5pm no matter what. My other college-educated co-workers are:
- more intelligent
- more hard working
- climbing the career ladder much faster
Now's the opportunity - jump in and learn all you can while you still can.
Brick, slate shingles, and really solid floor board / tile can also wreak havoc on 2.4ghz. I deployed a 802.11b AP in infrastructure mode in my basement and tried to attach to it from my upstairs bedroom. It was a no-go. Of course, my house was built in 1953 and has radiated heat, so that may have something to do with it. Also, tiled floors and the really thick floorboard that they used back then could cause problems. I also have plaster walls and while it doesn't totally kill the signal, it doesn't help... I've found that 2.4ghz goes through drywall much better than plaster (not surprisingly).
I also ran some experiments whereby I put an AP in the window, took a laptop outside with a signal meter, and walked around the house. Sure enough, the signal strength goes from 100% to 0% as soon as I walk into an area that is clipped by the brick. This corresponds to the poor cell phone reception that I get in my house. 1 or 2 bars and a tower is about 400yards away.
The thing to remember is most houses that are unable to receive DSL and/or cable are far from a central office because they are in an old neighborhood. Newer neighborhoods seem to have better connectivity (because getting connectivity is an issue today whereas it wasn't back in the 50's / 60's / 70's..). Thus, it wouldn't surprise me if the people who could really be served by a wireless last mile are people that're in an old neighborhood. If that assumption is true, then this implementation would be difficult due to the age of the house and how houses were constructed back then.
Can you be more specific as to what features are new in 3.0? I'm anxiously (and nervously) awaiting my upgrade. I'm afraid it'll wipe out my TurboNet installs and the IP info in my boxen...
Regardless of if/. is Linux-Centric - I think this review is here because there is really a lot of exciting work being done on the "Hacking TiVo" front. There are a lot of really *really* nifty (and promising) projects that're being actively worked on: tivo-web (tcl), ExtractStream, etc...
Beyond the exciting projects, the hacking of the TiVo itself is really a great experience. The folks at TiVo have been really positive (relatively speaking) in response to the hacking efforts. There is a rule that the hacking community has agreed to follow: don't fsck with the service code. There are no projects trying to steal service. Because of that, the TiVo folks have been really forthcoming with leaked information regarding system upgrades of the software (hints as to what devices will be supported and what-not) as well as some tools for manipulating the TiVo once it's r00t3|).
And from a purely hacking standpoint - the DTiVo was the most illuminating hack I've done. They really have some security built into that thing to prevent the casual passer by from hooking up the disk to a PC and typing "mount". Hats off to all the TiVo Community for all the tremendous efforts they've put into hacking that box...
Re:When will TiVo get ReplayTV network features?
on
TiVo Series 2 Review
·
· Score: 1
You can do this... Search on www.dealdatabase.com for ExtractStream. Definitely possible, although very difficult under the DTiVo's
I own two DTiVo's and 1 standalone TiVo. Both r00t3|) with ethernet. Hacking the DTiVo is a couple of order of magnitudes more difficult than hacking the standalone...
That's not necessarily true. I think that "good 'ole Bill" has several pop-shots through the year and the rest of the time he can coast. For example, say I hit the lottery and win $300 million as an up-front payment. If you look at my earnings per hour on the year, I earned about $163,043 per hour (1480 hours in a work year).
But really I only spent 25 minutes buying the lotto ticket and depositing my winnings. I could do whatever I wanted to the rest of the year and it doesn't effect my net earnings at the end of the year.
Likewise, Bill clinches a deal here, stifles some competition there, strongarms Dell into not selling Linux boxen anymore, and he pockets a boatload of cash on one day. Tomorrow he could sit in the crapper all day, and by the end of the week he's still fallen ass-backwards into money.
Slashdot Mirror
I think that a company should be able to control distribution channels of their content in electronic format. Where I believe I differ from most in the mechanism to achieve the control. They (the industry (purposely vague reference)) have chosen to invest $$$ in lawyers and lobbyists to create laws like the DMCA. When they believe somebody has stolen service, they pay more $$$ to more lawyers to prosecute. And then we (the defendants) pay $$$ for our own lawyers. And we go to court, which lots of times takes months. Bah! Net result: lots of $$$ spent, lawyers getting most of it. And what happens if somebody outside US jurisdiction violates the law? Is DTV going to travel to Afghanistan to hunt down Ahkmed Ahkmed Jallalbad for getting his "The Hot Network" fix? No. So the laws work great inside the US but don't work outside our borders. That's a winning strategy in an increasingly global economy!
... improve the technology. If DTV took all of the loot it spent prosecuting people and lobbying, I believe they could create a virtually uncrackable platform. Let's get PKI to be almost a household term. Let's get thumbprint identification on the remote controls of our satellite boxes that can authenticate our service. What's the net result with this approach? Fewer court cases, technology that can be exported beyond US borders, less government bullshit, and a happier more secure piece of equipment.
My alternative is to take all the $$$ that would be spent on lawyers, beurocrats, and lobbyists, and
I don't know why more people don't see it this way....
Yes I mind that you eavesdrop on my cell phone conversation. Should you have a right to? In my opinion yes. If the cellular telephone company makes the decision to *not* encrypt their channels, or if they do a piss poor job at encrypting their channels, then I would *expect* my conversation to be hacked.
In my opinion, the DTV signal argument postulated by AgentTim3 is similar to the telnet vs ssh debate. Let's say that you are a company that provides Unix shell accounts to people. In exchange for $$$, you offer service to a Unix account. If you provide telnet access, and somebody snoops the packets, steals a username and password, and breaks into your account - have they broken a law? Sadly yes (the DMCA).
Fact is the company should have used ssh as an interaction mechanism. Similarly, if somebody out there receives DTV's signal and decodes it, are they any more guilty than the guy who packet sniffed?
Unfortunately, both situations above are considered illegal. In my opinion this is another case of government attempting to regulate stupidity. If "Shells 'R Us" is dumb enough to offer telnet access, and consumers are dumb enough to use it, they deserve the repurcussions of having someone tear them a new one. Likewise, if DTV doesn't make the investment in equipment and software to stay ahead of the hacking community, then they deserve the diminished revenue they receive.
This will definitely get modded up for flamebait.
rsync is a great protocol, fairly robust, can be wrappered in ssh (or not), supports resuming transmission, and operates over one socket.
seems like the best of both worlds to me.
the real question is - do you control the clients that are going to access you? or is it something like a browser (which doesn't support rsync).
While you certainly received a solid cornerstone of XP (keeping inventory low), there are other aspects of the methodology that are easy to implement, and produce magnitudes of fruit. I'm afraid you might not have fully absorbed the XP message: communication, simplicity, and testing are the key tennants (imo of course).
A lot of people fall into the trap of relating the XP methodology to some familiar aspect of their current methodology. For example, a lot of my coworkers associate "stories" with "use cases" or "requirements". While use cases and requirements documents represent a subset of what a story represent, they fail to convey the communication and interaction with the customer essential to success. Moreover, stories are vehicles through which intent is transmitted between the customer and the programmer. I haven't been on a project yet where the customer wrote a use case, programmers disected it into small parts, estimated the effort required, handed it back to the customer, and asked the customer to define which use cases were the most important. More often than not, the customer does not even write the use cases, much less define which ones are to be implemented first. Often the programmers (or some manager associated with the development effort) write the use cases. And a lot of times, acceptance tests are not written to confirm the implementation of the use case. These concepts are all tangents around the XP methodology involving stories. Simply put, use cases are NOT the same as stories. XP Stories involve interaction, are estimated for time, are specified by the customer, are prioritized by the customer, and are verified by tests written by the customer. Use cases are just procedures.
Do you actually have a point or do you just enjoy rambling?
BTW, here's a fact - Frank Rhines (sp?) is the CEO of Fannie Mae, a company with so much annual revenue that they actually have a "trillion dollar day" (the day where they actually earned their trillionth dollar of revenue). Their revenue exceeds the GDP of all other countries in the world (except a small handful like Germany or England). Oh ya, and did I mention that he's black?
What's funny is that there were talks a year or so ago by the NAACP (or some other organzation) about Fannie Mae hiring too many "White Male" employees. Frank came out and said "hello, umm... I'm black. Why would I do that???" Momentum suddenly dwindled.
Get your facts straight, pull some examples, and make a point instead of rambling.
Light it up y'all.
Ain't gonna be another 4:20 release for a long time.
What is fascinating to me is the amount of effort people put into cooling their system to achieve a couple of hundred more mhz of power. I understand that it's more of a hobby than anything else - it's not like the owners are running nuclear detonation scenarios and the +100mhz allows them to finish their work 1 month sooner. And I respect that - I've hacked my TiVO and my SonicBlue audio receiver 'because I could'.
But what is pretty funny is that in 1 year, a 3.3ghz chip will be for sale out of the box. It must be kinda frustrating (maybe?) to put all this work into vapochilling your processor, installing a water-based cooling system, drilling blow-holes in the case, etc to achieve a N + M mhz processor (N is what the processor should run at, M is how much overclocking has been achieved) when an N + M mhz processor will come out in a year.
I suppose what's more remarkable is that the processor makers are able to produce faster and faster chips so quickly.
What a great time to be alive.
Your point is well taken. Simply opening a file format does *not* change anything. If MS is truly interested in interoperability with third party developers / scripters, they will make a concerted effort to document their XML as well as keep it consistent.
... In the end the only components interacting are the MS Word application and the MS Word'ed XML docs on your filesystem.
For example...
I work on an xml driven middleware project. We have gone to great lengths (via xsl scripts) to generate documentation that matches our dtds. We really focus on backwards compatibility and not breaking it, so as to happily interoperate with the community (specifically with older clients). If MS wants to continue to protect it's market position, they could *quite* easily "use xml" as their file format but obfuscate (via a volatile dtd) it enough that it becomes such a moving target that nobody *wants* to use it. Consider a bogus specification that states that the namespaces, element names, and overall structure completely change (unpredictably) if you have a regularly faced document vs a bold faced document.
What's my point? Don't assume that MS is opening their file format because they are using xml. It's a clever ploy on their part to say to the world (and more importantly to the DoJ) - 'look, we're inter-operating with the world because we use xml', but then not publish a DTD, not document, break backwards compatibility with every patch release, etc etc etc
Indeed. An often-times overlooked benefit of open-source is the exposure a product can attain simply by virtue of being open. A closed source product team has to make an investment in a quality assurance group, which usually works 9 - 5. An open source project (assuming it is highly visible) is capable of leveraging a global supply of quality assurance engineers to test their product 24 hours a day, 7 days a week. The whole world is essentially their beta testers.
While the Samba folks have done us Linux folk a tremendous favor (reverse engineering *any* protocol is difficult) in encapsulating all of the SMB details via Samba, they have also performed a huge service to MicroSoft and the rest of the closed-source world by hammering on the various platforms that come out of Redmond. As the article points out, every new version (or patch release) is put through it's paces against Samba. Although their primary goal is to ensure compatibility, the secondary effect is extremely valuable to non-Samba users: bugs in server software from a closed source vendor are exposed (and hopefully fixed).
The difficulty is that the rest of the world (and probably MicroSoft in particular), either doesn't see, or see's but turns a cold shoulder none-the-less to the open source community.
Thank you Andrew for your work and the work of your team.
How about the plumbing? In the US, most homes come with a 3/4 inch aluminum pipe from the street to feed water. Are they the same where you live? Usually, the location that the pipe enters the house is underground and in a utility room or furnace room. You could use that room to drill another 3/4 inch pipe parallel to the water pipe out to the central sewer / water tunnel.
In the furnace room of each house, install an access point. Generally, 2.4ghz bounces off of concrete (but has a tough time going through it). Once you get the signal inside the house, it shouldn't be hard to get it from the basement to the attic.
It sounds to me that the jump between houses is the hard part. Solve that and you've got your problem licked. Perhaps the sewer system will work...
The ring lasted for about a year before the amethyst point worked its way loose. I Krazy-glued it in and it stayed in for a few weeks more before I lost it for good.
You're so ghetto...
From the article:
This article imagines a "Java 3" that jettisons the baggage of the last decade, and proposes numerous changes to the core language, virtual machine, and class libraries. The focus here is on those changes that many people (including the Java developers at Sun) would really like to make, but can't -- primarily for reasons of backwards compatibility.
In other words, Elliotte fully understands *why* his proposed changes would be difficult to implement. His 10 changes are contingent upon the assumption that you can break backwards compatibility.
It doesn't seem totally unreasonable to me. Microsoft forces people to upgrade their OS in order to support newer versions of their Office product. While I'm definitely not a Microsoft advocate, I believe that forced upgrades aren't necessarily a "bad thing."
Assuming Java 3.0 were implemented and backward compatibility was broken, Sun wouldn't pull the downloads for Java 2.0 off their websites. Moreover, a magical wave of energy won't wash over the planet halt'ing all Java 2.0 and 1.0 applications and permanently erasing their JDK installations. The 2.0 and 1.0 Java applications would simply become "legacy" code until such time that they are either replaced or updated to the new Java 3.0. In fact, it would not surprise me if a significant number of the apps were not migrated (because they were not judged important enough to spend money to upgrade) and continued to execute under the old Java.
The authors of Java 1.0 and Java 2.0 applications didn't have the benefit of coding under the "3.0 conventions". If the applications they wrote could really benefit from the changes, the authors will go back and refactor. If not, the application will continue to run in it's current form for years to come.
Upgrades are like refactorings. While toothless ones are trivial, they rarely provide significant benefit. It's usually the difficult upgrades (EJB 1.1 to 2.0?) that provide real opportunity for advancement. The 10 proposals by Elliotte seem like an example of the latter.
There was nothing in the article about the technical progress of Linux. It was all external uses of Linux. Interesting to some people. But I wanted to see stuff like: May 13, 1994: Donald Becker (becker@cesdis) writes the first 3Com driver.
Those are the tear-jerking memories that I wanna read about!
Things to *not* do:
- abbreviate variables
- define all your variables at the top of a method
- document how the method is doing what it does
Why *not*?
- abbreviate variables.
This enables naming collisions. For example: AddressInformation ai and AssertionInclude ai. If a maintainer has recently been in the assertion portion of the application logic, and is dropped into the user component (and comes across ai), they may make a mistake
- define your variables at the top of the method
Defining (and instantiating) variables only before the blocks of code where they are required adds extra meta-information to those variables. Blindly defining them at the top can lead to situations where blocks of code are removed from a method, but variables are not removed because they are defined and instantiated many lines above the block of code that was removed.
- define how the method is doing what it does
A comment of "iterates over the array specified, and performs a binary search of the class member foo, checking for equality with any of the elements" is meaningless to me at an API level. "compares the provided array with the internal state returning true if they are equal" is much more meaningful
Lots of luck to you on this. On my project it's really hard to get people to write good documentation. I don't know C++ very well at all, but a useful exercise for us Java programming folks (and maybe there is some analogy in the C++ realm that I'm not aware of) is looking at JavaDoc's first. If you are on a project with 500+ classes and you need to use an instance of some other class in the system, pull up it's JavaDoc information. Don't pull up the source. When you pull up the source, you tend to look at the actual code to figure out what the method does. If you look at the API you are evaluating the quality of the documentation. This leads to better documentation (because people realize the current documentation is inadequate) as well as a better developer knowledge. Treat your own internal API as an external library (like xerces). See how well the two stand up in terms of clarity and ambiguity. It's certainly the best lesson I've learned...
lmao
Even given the arguments against going to college, I would still go for the experience. I've seen countless folks who've not gone to college (that I now work with!) who are paid well, but do not possess the "got to get this working no matter what" attitude that one gets while attending a formal college. Those co-workers are the 9-5'ers who call it quits at 5pm no matter what. My other college-educated co-workers are:
- more intelligent
- more hard working
- climbing the career ladder much faster
Now's the opportunity - jump in and learn all you can while you still can.
Brick, slate shingles, and really solid floor board / tile can also wreak havoc on 2.4ghz. I deployed a 802.11b AP in infrastructure mode in my basement and tried to attach to it from my upstairs bedroom. It was a no-go. Of course, my house was built in 1953 and has radiated heat, so that may have something to do with it. Also, tiled floors and the really thick floorboard that they used back then could cause problems. I also have plaster walls and while it doesn't totally kill the signal, it doesn't help... I've found that 2.4ghz goes through drywall much better than plaster (not surprisingly).
..). Thus, it wouldn't surprise me if the people who could really be served by a wireless last mile are people that're in an old neighborhood. If that assumption is true, then this implementation would be difficult due to the age of the house and how houses were constructed back then.
I also ran some experiments whereby I put an AP in the window, took a laptop outside with a signal meter, and walked around the house. Sure enough, the signal strength goes from 100% to 0% as soon as I walk into an area that is clipped by the brick. This corresponds to the poor cell phone reception that I get in my house. 1 or 2 bars and a tower is about 400yards away.
The thing to remember is most houses that are unable to receive DSL and/or cable are far from a central office because they are in an old neighborhood. Newer neighborhoods seem to have better connectivity (because getting connectivity is an issue today whereas it wasn't back in the 50's / 60's / 70's
Just my 2 cents..
ya course not... you definitely should hang it behind a firewall and portforward only from privileged hosts (ie: my work PC)
Can you be more specific as to what features are new in 3.0? I'm anxiously (and nervously) awaiting my upgrade. I'm afraid it'll wipe out my TurboNet installs and the IP info in my boxen...
To me it's one of those things where TiVo just "sucks less" than any alternative (having my TV on my desk near my PC; using a VCR)...
Sure stuff'll get better in the future. But for now - TiVo takes the cake imo.
Regardless of if /. is Linux-Centric - I think this review is here because there is really a lot of exciting work being done on the "Hacking TiVo" front. There are a lot of really *really* nifty (and promising) projects that're being actively worked on: tivo-web (tcl), ExtractStream, etc...
Beyond the exciting projects, the hacking of the TiVo itself is really a great experience. The folks at TiVo have been really positive (relatively speaking) in response to the hacking efforts. There is a rule that the hacking community has agreed to follow: don't fsck with the service code. There are no projects trying to steal service. Because of that, the TiVo folks have been really forthcoming with leaked information regarding system upgrades of the software (hints as to what devices will be supported and what-not) as well as some tools for manipulating the TiVo once it's r00t3|).
And from a purely hacking standpoint - the DTiVo was the most illuminating hack I've done. They really have some security built into that thing to prevent the casual passer by from hooking up the disk to a PC and typing "mount". Hats off to all the TiVo Community for all the tremendous efforts they've put into hacking that box...
You can do this... Search on www.dealdatabase.com for ExtractStream. Definitely possible, although very difficult under the DTiVo's
I own two DTiVo's and 1 standalone TiVo. Both r00t3|) with ethernet. Hacking the DTiVo is a couple of order of magnitudes more difficult than hacking the standalone...
I really don't understand how they can peddle that piece of crap onto a consumer and make profit...
I get it to break if I click pages too quickly in IE.
zug-zug
That's not necessarily true. I think that "good 'ole Bill" has several pop-shots through the year and the rest of the time he can coast. For example, say I hit the lottery and win $300 million as an up-front payment. If you look at my earnings per hour on the year, I earned about $163,043 per hour (1480 hours in a work year).
But really I only spent 25 minutes buying the lotto ticket and depositing my winnings. I could do whatever I wanted to the rest of the year and it doesn't effect my net earnings at the end of the year.
Likewise, Bill clinches a deal here, stifles some competition there, strongarms Dell into not selling Linux boxen anymore, and he pockets a boatload of cash on one day. Tomorrow he could sit in the crapper all day, and by the end of the week he's still fallen ass-backwards into money.