Ah, magnets...the never-ending source of fascination for crackpots in need of remedial highschool science. If you just arrange them in the right configuration that no-one before has tried, align them just right... After all, you can push pins and stuff around with a magnet THROUGH a table top, there has GOT to be magic in there.
Uh, let's start with the CDMA+GSM thing, never mind all the other features you want. Can you find me a single combination CDMA+GSM phone, regardless of how feature poor? Any?
Depends entirely on what you mean by optimal viewing distance. The THX recommendation is a 36 degree viewing angle. At DVD resolution it's kind of hard to achieve that without seeing pixels.
The main difference it can make in home viewing is to allow a larger picture at the same seating distance. I'm thinking here primarily projectors, where zooming the picture up while still being seated 12 ft from the screen won't reveal ugly pixels. Other than that, I don't think the benefits justify the current prices just yet.
> Personally, FileNET is probably the tops of the list, but is extrodinarily expensive. > JBoss is the cheapest (free), but requires extreme customization.
It depends entirely on how well it works for you out-of-the-box. In my experience, the larger the company and the more different departments and groups have to be satisfied, the more likely off-the-shelf packages will be tweaked and customized to hell. At that point a less capable system that allows a high level of customization at the code level can be more valuable than a very powerful system that is closed to changes. Our company uses FileNET, and I've spent the last six years coding in and around it. Unfortunately it is a collection of different products (certainly the pre-P8 stuff), some COM and ASP, others Java (such as the workflow stuff). The ASP+COM stuff is quite highly customizable (which we have done, creating an essentially completely new Panagon front-end), while the eProcess stuff is sometimes less so. Things can usually still be hacked one way or another, but considering the large amount of customization we've done, we've often wondered ("we" the developers that is, not so much "we" the purchasing decision makers) if we'd have been better off with a less ambitious product that allowed more low level tweaking. In fact, since we pretty much redid the entire GUI (both web and "heavy client"), which is a significant part of the product, we sometimes wondered what exactly the added value of buying FileNET was. The temptation was sometimes high to just implement the back-end ourselves as well.
> A lot of people might shoot me for saying this, but it turns out that the Unified Process was pretty much a fad
Really, they will shoot you? Who exactly? Dig through Usenet posts of the last ten years and you will find mountains of complaints and cursing over UML and Rational in particular. This is a classic example of something developed by people with a serious disconnect from the Real World. It's a little like those beautiful example programs for OOP in college, where everything gels together wonderfully and anything that doesn't fit the paradigm nicely is conveniently not mentioned.
Yeah, but.NET goes far beyond that by making these compiled class extensible from another language. You can extend a C# class in VB.NET without needing its source code, and vice versa.
Yeah, $200 - $250 would be a very decent price point. In fact, for the Western markets they should simply skip the gimmicky "buy one and donate x" and simply set the price so a portion of it goes towards that automatically.
Yeah, a grayscale TFT screen without or with an optional backlight would seem to provide signigicant power savings. But it's probably a matter of availability and economies of scale--all R&D is in color TFT screens, so those are likely to be the cheapest. A monochrome screen nowadays would have to be a custom development, driving up costs.
The crank has now been incorporated into the screen hinge--you tilt the screen back and forth in a pumping motion to charge the battery. The little ears on top are really just grab handles for a better pumping action.
> Laptops have so much custom hardware these days that it's a Bad Idea(TM) to attempt an OS installation from anything but restore CDs.
Au contraire, laptops have more generic hardware in them than EVER before. A modern laptop--especially a cheapo like he used--resembles a desktop internally a lot more than the exterior may indicate. Only the name brands tend to include proprietary hardware cruft that needs specialized drivers anymore.
That is true and can't seriously be argued with, except to say that more than one type of help can be offered at the same time. Problems don't have to be addressed sequentially, because you can't seriously say that "once we've solved the hunger issue, we'll attack the technology bit." Hunger will possibly never be solved for all people on the planet, so we may never get to step 2 for those people whose hunger problem IS solved. Besides, people like Negroponte are technologists, not social workers or humanitarians of the food acquring type. He tries to help in the ways HE knows how, while AT THE SAME TIME others can do THEIR best in the food etc. departments.
Yes, full circle back to the tiled window days of Windows 1.0. That's a concept that has died an early death for good reasons, but I guess some people just can't leave dead horses alone. Tiled windows suck so much that they had to add the "zeroth column" hack to support floating windows to show just how much they suck. Ok, at times tiling can be very useful to maintain some visual order in a set of windows, but **optional** tiling has been implemented much more usefully (and optionally) via docking windows, a la Visual Studio.NET or many similar applications.
Another way of looking at it is this: the more sensitive or incriminating the encrypted data is, the higher the incentive NOT to hand over the keys. Quite likely the penalty for failure to comply would be considerably less than being incriminated by the data, especially in the two cases of paedophilia and terrorism. So as usual, the ones being punished the most are the ones from whom there is the least to be gained: the innocent.
> I think you might be mis-interpreting what this thing does.
Wow, I got this completely wrong. I admit I didn't RTFA, and simply assumed JSP or something like that as soon as I saw Java mentioned. This thing actually creates clean HTML+JavaScript files, which you're right, you can simply integrate with existing server side code. In fact, I may have to play with this some.
> I could easily extend this argument and say that everyone just needs to learn assembler.
Actually, that would be wrong, since the lowest practical denominator are the OS APIs, not CPU registers. The language is quite immaterial.
> should I really need to learn every intricacy of the bugs in the DOM of IE vs. Mozilla in order to be productive with AJAX?
You shouldn't have to, but it helps. Besides, these frameworks address a lot more than just AJAX--in fact, some don't even address AJAX at all. The real issue here is the abstraction of page creation on the server side. Instead of generating raw HTML+JavaScript from within server-side executable pages (PHP, ASP etc.) using a language that doesn't introduce any serious abstractions, we are now creating web pages as a side effect of manipulating fairly abstracted classes. This is nifty and very productivity enhancing, but you are developing around a different paradigm, and different frameworks will have slightly different takes on this paradigm. And if there are bugs or glitches in the framework, you have to drop down to HTML+JavaScript and examine the client side code that is generated to see what the problem is. Then you have to dig through the framework classes to find where the problem is, provided you even have access to the source code. A good framework will give you lots of opportunities to intervene in the page creation process to manipulate the final output.
Anyway, my main concern is that when you move away from PHP or ASP (which mainly differ in syntax more than anything else) and target a particular framework as your lowest level API (so to speak), you become dependent on that particular paradigm. Switching to a different framework may require considerable relearning of class hierarchies and the way things are done. Still, given a significant overall productivity jump, this may be acceptable overall.
> you are coding your website in Java, using their API and SWT-like objects, and the Javascript/Ajax is then generated from your classes.
Which is also the greatest danger of such toolkits. Once you learn something like this, you know the framework but you know less and less about the underlying technologies. You can learn this framework, or you can learn ASP.NET, or Ruby on Rails, or whatever, which are all very different ways of accomplishing the same thing. I'm not saying that this is bad overall, since they all lead to productivity enhancement. But each framework has a considerable learning curve, leading to developers becoming more and more specialized and married to a particular implementation of a technology. This is not unlike the RAD tools of the past, where one could become very proficient in VB6 or MFC or the VCL, while losing more and more touch with the win32 API. I guess the trick is to try to keep up with the lower level technologies that these frameworks abstract.
More like.NET isn't ready for AJAX. AJAX doesn't really use any new web technologies, it just applies existing ones in a somewhat new way. ASP.NET OTOH is a framework that tries to completely shield the developer from the underlying web technologies, and it does so with varying degrees of success, in the process turning out web technology idiots.
> Did I give some sort of time frame that you're disputing, or is this another case of > a trigger-fingered slashdotter prematurely blowing their "Bull!".
A little bit of both. You did imply a timeframe by talking about "1000 phone calls between two cities", which would definitely put this at the turn of the century, but OTOH you could have just meant that figuratively, in which case was trigger-happy for sure.
However, around the turn of the century mechanical multiplexers were already used. I used to have some ancient books on telephone technology that went into a fair bit of detail on that sort of thing, such as the rotary multiplexers used. However, not much stuff shows up on Google along those lines, even though I must have searched for a couple of hours last night. The language on the AT&T page is vague enough to not preclude the use of multiplexers. When they talk about two pairs of wires carrying "three calls" they could simply mean three simultaneous electrical circuits before multiplexing. I seem to remember mechanical multiplexers being able to combine up to 20 or 30 simultaneous calls. However, at this point I can't offer any references, but would be extremely interested in finding some.
Actually, the biggest potential wire savings came with digital signalling. A digital bus (acutally, multiple redundant ones) runs the length of the fuselage and through the wings, and subsystems jack into this bus with the shortest possible wire run. The 747 has so much wire because of the huge number of home runs to central control units. While there may have been a small amount of digital control, I'm quite sure the norm was good old analog end-to-end circuits for each sensor and actuator.
> If there were 1000 phone calls between two cities, then there had to be at least 1000 copper pairs to support them.
Bull, except in the very early days of telephony, that simply wasn't the case. Mechanical multiplexers were developed very early on, since the need for a separate long distance circuit per connection was considered absurd even in the wire-happy 19th century. Check out US patent 0161,739. Later on CRT multiplexers were used, where each connection was represented by one pixel which was modulated by the voltage of that circuit, to be finally displaced by electronic and then digital multiplexers. The ealier history of telephony is actually an extremely fascinating subject, full of ingenious yet obscure technology.
Slashdot Mirror
Ah, magnets...the never-ending source of fascination for crackpots in need of remedial highschool science. If you just arrange them in the right configuration that no-one before has tried, align them just right... After all, you can push pins and stuff around with a magnet THROUGH a table top, there has GOT to be magic in there.
Wow, I had no idea there was such a beast. I stand corrected.
Uh, let's start with the CDMA+GSM thing, never mind all the other features you want. Can you find me a single combination CDMA+GSM phone, regardless of how feature poor? Any?
Depends entirely on what you mean by optimal viewing distance. The THX recommendation is a 36 degree viewing angle. At DVD resolution it's kind of hard to achieve that without seeing pixels.
The main difference it can make in home viewing is to allow a larger picture at the same seating distance. I'm thinking here primarily projectors, where zooming the picture up while still being seated 12 ft from the screen won't reveal ugly pixels. Other than that, I don't think the benefits justify the current prices just yet.
> I'm going to be living in a student house with 4 (inc. me) heavy internet users.
Get some sturdy seats--preferably recliners with build-in cup holders--and you should be fine.
> AMD went to work right away to support our common goal - winning the Tour de France.
I'm glad that worked out so well for Team Discovery, especially without Amstrong.
> Personally, FileNET is probably the tops of the list, but is extrodinarily expensive.
> JBoss is the cheapest (free), but requires extreme customization.
It depends entirely on how well it works for you out-of-the-box. In my experience, the larger the company and the more different departments and groups have to be satisfied, the more likely off-the-shelf packages will be tweaked and customized to hell. At that point a less capable system that allows a high level of customization at the code level can be more valuable than a very powerful system that is closed to changes. Our company uses FileNET, and I've spent the last six years coding in and around it. Unfortunately it is a collection of different products (certainly the pre-P8 stuff), some COM and ASP, others Java (such as the workflow stuff). The ASP+COM stuff is quite highly customizable (which we have done, creating an essentially completely new Panagon front-end), while the eProcess stuff is sometimes less so. Things can usually still be hacked one way or another, but considering the large amount of customization we've done, we've often wondered ("we" the developers that is, not so much "we" the purchasing decision makers) if we'd have been better off with a less ambitious product that allowed more low level tweaking. In fact, since we pretty much redid the entire GUI (both web and "heavy client"), which is a significant part of the product, we sometimes wondered what exactly the added value of buying FileNET was. The temptation was sometimes high to just implement the back-end ourselves as well.
> A lot of people might shoot me for saying this, but it turns out that the Unified Process was pretty much a fad
Really, they will shoot you? Who exactly? Dig through Usenet posts of the last ten years and you will find mountains of complaints and cursing over UML and Rational in particular. This is a classic example of something developed by people with a serious disconnect from the Real World. It's a little like those beautiful example programs for OOP in college, where everything gels together wonderfully and anything that doesn't fit the paradigm nicely is conveniently not mentioned.
Yeah, but .NET goes far beyond that by making these compiled class extensible from another language. You can extend a C# class in VB.NET without needing its source code, and vice versa.
Yeah, $200 - $250 would be a very decent price point. In fact, for the Western markets they should simply skip the gimmicky "buy one and donate x" and simply set the price so a portion of it goes towards that automatically.
Yeah, a grayscale TFT screen without or with an optional backlight would seem to provide signigicant power savings. But it's probably a matter of availability and economies of scale--all R&D is in color TFT screens, so those are likely to be the cheapest. A monochrome screen nowadays would have to be a custom development, driving up costs.
The crank has now been incorporated into the screen hinge--you tilt the screen back and forth in a pumping motion to charge the battery. The little ears on top are really just grab handles for a better pumping action.
> Laptops have so much custom hardware these days that it's a Bad Idea(TM) to attempt an OS installation from anything but restore CDs.
Au contraire, laptops have more generic hardware in them than EVER before. A modern laptop--especially a cheapo like he used--resembles a desktop internally a lot more than the exterior may indicate. Only the name brands tend to include proprietary hardware cruft that needs specialized drivers anymore.
That is true and can't seriously be argued with, except to say that more than one type of help can be offered at the same time. Problems don't have to be addressed sequentially, because you can't seriously say that "once we've solved the hunger issue, we'll attack the technology bit." Hunger will possibly never be solved for all people on the planet, so we may never get to step 2 for those people whose hunger problem IS solved. Besides, people like Negroponte are technologists, not social workers or humanitarians of the food acquring type. He tries to help in the ways HE knows how, while AT THE SAME TIME others can do THEIR best in the food etc. departments.
Yes, full circle back to the tiled window days of Windows 1.0. That's a concept that has died an early death for good reasons, but I guess some people just can't leave dead horses alone. Tiled windows suck so much that they had to add the "zeroth column" hack to support floating windows to show just how much they suck. Ok, at times tiling can be very useful to maintain some visual order in a set of windows, but **optional** tiling has been implemented much more usefully (and optionally) via docking windows, a la Visual Studio .NET or many similar applications.
Another way of looking at it is this: the more sensitive or incriminating the encrypted data is, the higher the incentive NOT to hand over the keys. Quite likely the penalty for failure to comply would be considerably less than being incriminated by the data, especially in the two cases of paedophilia and terrorism. So as usual, the ones being punished the most are the ones from whom there is the least to be gained: the innocent.
> I think you might be mis-interpreting what this thing does.
Wow, I got this completely wrong. I admit I didn't RTFA, and simply assumed JSP or something like that as soon as I saw Java mentioned. This thing actually creates clean HTML+JavaScript files, which you're right, you can simply integrate with existing server side code. In fact, I may have to play with this some.
> I could easily extend this argument and say that everyone just needs to learn assembler.
Actually, that would be wrong, since the lowest practical denominator are the OS APIs, not CPU registers. The language is quite immaterial.
> should I really need to learn every intricacy of the bugs in the DOM of IE vs. Mozilla in order to be productive with AJAX?
You shouldn't have to, but it helps. Besides, these frameworks address a lot more than just AJAX--in fact, some don't even address AJAX at all. The real issue here is the abstraction of page creation on the server side. Instead of generating raw HTML+JavaScript from within server-side executable pages (PHP, ASP etc.) using a language that doesn't introduce any serious abstractions, we are now creating web pages as a side effect of manipulating fairly abstracted classes. This is nifty and very productivity enhancing, but you are developing around a different paradigm, and different frameworks will have slightly different takes on this paradigm. And if there are bugs or glitches in the framework, you have to drop down to HTML+JavaScript and examine the client side code that is generated to see what the problem is. Then you have to dig through the framework classes to find where the problem is, provided you even have access to the source code. A good framework will give you lots of opportunities to intervene in the page creation process to manipulate the final output.
Anyway, my main concern is that when you move away from PHP or ASP (which mainly differ in syntax more than anything else) and target a particular framework as your lowest level API (so to speak), you become dependent on that particular paradigm. Switching to a different framework may require considerable relearning of class hierarchies and the way things are done. Still, given a significant overall productivity jump, this may be acceptable overall.
> you are coding your website in Java, using their API and SWT-like objects, and the Javascript/Ajax is then generated from your classes.
Which is also the greatest danger of such toolkits. Once you learn something like this, you know the framework but you know less and less about the underlying technologies. You can learn this framework, or you can learn ASP.NET, or Ruby on Rails, or whatever, which are all very different ways of accomplishing the same thing. I'm not saying that this is bad overall, since they all lead to productivity enhancement. But each framework has a considerable learning curve, leading to developers becoming more and more specialized and married to a particular implementation of a technology. This is not unlike the RAD tools of the past, where one could become very proficient in VB6 or MFC or the VCL, while losing more and more touch with the win32 API. I guess the trick is to try to keep up with the lower level technologies that these frameworks abstract.
More like .NET isn't ready for AJAX. AJAX doesn't really use any new web technologies, it just applies existing ones in a somewhat new way. ASP.NET OTOH is a framework that tries to completely shield the developer from the underlying web technologies, and it does so with varying degrees of success, in the process turning out web technology idiots.
> Did I give some sort of time frame that you're disputing, or is this another case of
> a trigger-fingered slashdotter prematurely blowing their "Bull!".
A little bit of both. You did imply a timeframe by talking about "1000 phone calls between two cities", which would definitely put this at the turn of the century, but OTOH you could have just meant that figuratively, in which case was trigger-happy for sure.
However, around the turn of the century mechanical multiplexers were already used. I used to have some ancient books on telephone technology that went into a fair bit of detail on that sort of thing, such as the rotary multiplexers used. However, not much stuff shows up on Google along those lines, even though I must have searched for a couple of hours last night. The language on the AT&T page is vague enough to not preclude the use of multiplexers. When they talk about two pairs of wires carrying "three calls" they could simply mean three simultaneous electrical circuits before multiplexing. I seem to remember mechanical multiplexers being able to combine up to 20 or 30 simultaneous calls. However, at this point I can't offer any references, but would be extremely interested in finding some.
Actually, the biggest potential wire savings came with digital signalling. A digital bus (acutally, multiple redundant ones) runs the length of the fuselage and through the wings, and subsystems jack into this bus with the shortest possible wire run. The 747 has so much wire because of the huge number of home runs to central control units. While there may have been a small amount of digital control, I'm quite sure the norm was good old analog end-to-end circuits for each sensor and actuator.
> I woudn't want to put my life on the line on that airplane though
Given its length of 3m, I wouldn't either.
> If there were 1000 phone calls between two cities, then there had to be at least 1000 copper pairs to support them.
Bull, except in the very early days of telephony, that simply wasn't the case. Mechanical multiplexers were developed very early on, since the need for a separate long distance circuit per connection was considered absurd even in the wire-happy 19th century. Check out US patent 0161,739. Later on CRT multiplexers were used, where each connection was represented by one pixel which was modulated by the voltage of that circuit, to be finally displaced by electronic and then digital multiplexers. The ealier history of telephony is actually an extremely fascinating subject, full of ingenious yet obscure technology.