The big problem seems to be that the concentration isn't on traffic even with hands-off versions of mobile phones. True enough, there is not that gross inattentiveness associated with reading or writing text-messages, or other non-telecomms activities like applying makeup or reading the newspaper. Still, the concentration isn't where it ought to be during phone calls, I have experienced this myself, being on "autopilot" whilst talking. Enough to keep the vehicle following the road; but at the end of the conversation I realized I could not remember anything of what I had passed, even obvious things like small towns and intersections.
On the other hand, this idea of being able to quickly get commands across to various in-car systems seems exciting. Being able to turn on a music selection with a flick of the wrist certainly is vastly better than an in-car entertainment system full of pushbuttons. I got one of these here, and I never am able to work it unless the car is stationary.
For an added twist, make sure to put junk-mail replies from some other company into any of these envelopes.
Unfortunately, I am not sure if this really works, and there still is the matter of having to go and put it into the post -- the fireplace is not so far away and appears to me to be an easier choice.
I don't think Mom (or even Dad) raise anywhere as many difficulties as does the 13-year
old nephew who wants all the latest games for his PC. Never mind MS-Office vs OpenOffice, all my older folks use only a few key applications, and it is not inconceivable that they could manage to switch from Windows to Linux and still be able to do what they want.
It is the younger crowd who currently has the most problems with stuff not working under one or the other of Windows ME, Windows 2000, and Windows XP. Throwing WINE on several varieties of Linux into this fray will not really help...
I didn't have any problems with reading the site at the time of this posting, but I can see where his headaches with C++ might have come from. The MSVC versions of STL hasn't been around in a standard form for very long, although the MFC library has been. This is most likely the grounds for the complaint. And the MFC does not make for easy portability to native Linux/Unix environments.
However, designing things in C++ and doing it properly is damn tough; many designs may seem easy to begin with, but then run into trouble with things like multiple inheritance from related parents, or simply that encapsulation is difficult because of the need for exposing the inner workings of classes... STL fixes some of this at the expense of code bloat -- it is easy to produce executables tens of megabytes in size.
Another problem with C++ which has been bothering me, and I would presume, the developers of Peekabooty, is the tendency towards static compilation and inclusion of everything. I looked at the source files here, and the sheer number of include-files compared to source files indicate that this probably does not compile quickly.
There is a way around this, if the application can be divided into several major and fairly independent components which then are compiled and linked as a number of dynamical libraries (.DLLs on Windows,.so on Linux and Unix). Now, with proper design, recompiling the whole lot is not necessary for smaller changes within one of the parts where no changes in this part has taken place. The trick here is encapsulation: do not let code in any one part know about any of the internal structure of code in any other part.
In fact, while they had the "voltmeter" terminals connected, the voltage was going up. Proof of an amazing breakthrough I say.
Or a capacitor or battery recovering after a heavy load has been disconnected. This phenomenon is fairly well known to people doing electronic design, it may not be so well-known to the public at large, and there is definitely a big "gee-whiz" effect to it.
One good reference I know of is this
article by Robert A. Pease.
Jonson? I guess you mean Jon Lech Johanson, or "DVD-Jon".
Jon Lech Johanson was acquitted on charges of having made it possible to extract information from DVD, which as it turned out, he had the rights to do as long as he had paid for the right to watch what is on these DVDs. The relevant part of Norwegian law involved originally had to do with reading other peoples letters.
Since then, the prosecutors have appealed and will have the case tried again in the next higher level court, Lagmannsretten. They cannot press any additional or different charges, the question will still be if it is legal to break
into one's properly licensed DVDs.
However, although the charges were initiated by a record companies association, this still was properly handled in a court of law, not through some kind of Internet vigilantism as is being discussed here.
1. A forensics-style device like this seems to me to be very
similar to the practice of measuring blood alcohol levels of drivers in accidents. It is
one more item of information about what happened at the time, and may indicate culpability
or innocence, as others here have said. As long as this information is only obtained after an accident and
indicates the conditions at that point, it is OK.
2. In this case, the evidence from the black box did not by itself decide the case. The speed
limit was 30 MPH, he said he was going 60 MPH, the investigator estimated 98 MPH and the EDR
indicated 114 MPH. Now, 60, 98, or 114 in a residential 30 zone is reckless driving anyways.
All this proved was that he was lying,
3. There was no problems with unreasonable search, in as much as the judge had issued a search warrant for this information.
4. The problem is with automated prosecution, which is what traffic-cameras are,
and some say this could be turned into. Combined with GPS and tables of speed limits and such.... Seems this enormous focus on speed to the detriment of other dangerous behavior is caused
because speed is easy to measure. I do not for a second believe that we will be any safer with people going 30 MPH, behaving like zombies. Just because the speed limit is 30.
This is far too focused on speed limits, making the assumption that the speed limit is always identical to the safe or optimal speed. I don't think I would want to take advantage of the +15 MPH bonus past a school at any rate....
Tapping geothermal energy, for heating houses at least, is simply a matter of drilling a deep well (some 150 m down) and using a heat pump to extract the heat energy from the ground and use it to keep the house and its inhabitants warm during the winter.
A geothermal power plant could conceivably be made in a similar way, but on a larger scale.
However, you don't have to live close to any volcano for this to work. The heat is there in the underground everywhere.
It is interesting to note that some new cars' engines run so efficiently that they no longer produce enough heat to keep the driver and passengers warm during cold weather. (say below 32 F or 0 C) I have experienced this firsthand with a recent Mercedes E-series car, with a diesel engine. This car is equipped with an auxiliary electrical heater, since the heat from the cooling water from the engine simply isn't enough. Without it, it would be like the old air-cooled Volkswagens, which were infamous for their weak heating.
Certainly, some kind of reversible heat pump which can do double duty as an airconditioner during the summer would be very useful.
In the entry on Hacker Personality, ESR tells about how he managed to remember the 477 pages of the TeX-book in 4 days. By itself this is quite impressive.
However, I cannot help but get the impression of someone bragging of themselves. Such personal anecdotes do not really belong in a reference work. And I am not really sure about whether this is a good example of what hackers do. To me, their main trait is that they create, rather than memorize, things.
One might argue that one never should call oneself a hacker, but this appears to be OK once the title has been bestowed by others.
Re:Portions of infringing code revealed
on
Latest SCO News
·
· Score: 1
hehehe... I liked the joke.
However, I do hope that the code and associated comments do not look like this or some of the other examples I have seen around here. That has less to do with this whole damn SCO debacle, than with the code quality in general.
i++; already tells anyone in the know that i gets incremented by one, there is no need for a comment explaning this fact! Any comment at this level, if necessary at all, should be telling us something about the reason for this incrementing, if this was not already obvious from context. Comments repeating the C statement in English is a waste of space.
This kind of commenting is a strong indication that the author of the code did a less-than-excellent job.
To the extent this isn't moot, insofar as whoever signs this NDA and sees the disputed source code, cannot say anything about what he has seen. Then, what is up with this partial source? Why isn't SCO wanting to show all of it?
Let us now assume that someone will be sufficiently bold and/or daft so as to actually go ahead and sign this NDA, and thus get to see this fabled source code.
SCO shows some part of the code, it is anybody's guess what or how much it will be, but there will be some nevertheless. There are two possible outcomes:
Either the code seen is discovered to be infringed, and SCO has a case, although whoever saw this cannot say so, upon his head be it.
Or the code is not infringed. The professional who has seen the code still may not tell, but this time there's really nothing to say either: some other code in there could still be infringed and the only conclusion is that time has been wasted.
Either way, this comes out slightly less than useful. No wonder not many have bothered.
The word "inlandsis", which is used in French and Spanish, most likely comes from Scandinavia. The Norwegian spelling would be "innlandsis", which simply means "ice over land" or "inland ice". This word is a techical term in Norwegian as well.
I have seen the English terms "ice sheet" and "continental glacier" for this.
Re:12v Power Over CAT5?
on
PeltierBeer
·
· Score: 1
The CAT5 cable is most likely rated at least 30V, possibly more, so 12V is well below the maximum.
I'd be more concerned about current capacity and even power loss, since the usual CAT5 (as seen in the pictures) is only 24 AWG in size.
The RJ45-connectors at the ends are not high-current either, I have seen numbers in the order of 1A per connector. Even connecting wires in parallell limits you to 4A total (4 wires each way, for 1A each), and the PC power supply used is certainly able to deliver more current than this. Then there is the potential for miswiring and plugging the 12V cable into a laptop network port, which doesn't sound too healthy for either device.
My estimate is that these connectors will become fried before the cable itself once something tries to draw too much current.
Ordinary lamp cord or speaker cable (2*0.75 mm^2 should be readily available) would be a better choice for this application.
IANAL, but I have been involved in a patenting process and subsequent litigation. There was talk about the concept of independent invention, which means that if someone comes up with a solution that someone else has a patent on, the situation isn't a clear-cut matter of infringement.
The next question to ask would be about the timing of this: Which specific functions and features of the kernel are under fire here? And when were these put into the kernel?
And finally, isn't SCO becoming engaged in barratry here?
Not just warning of the address being broadcast, but formatted to appear to come from an IE session on Windows XP... Except that I was running Opera on Gnome at the time so my reaction wasn't the hoped-for "oh I'm insecure" but rather "Who're you fooling?"
Up until sometime in 2001 or 2002 when they replaced the picture of Michael Faraday with the picture of Edward Elgar on the 20s, I guess one could say that a pound was 0.05 Farads....
The weight pound corresponds to the weight of a mass of 0.454 kg. The pound as a unit is thus really a force unit, with the same dimension as the SI unit Newton. So 1 lb = 0.454 kg*9.81 m/s^2 = 4.45374 N.
1 Pound-mass would thus be 0.454 kg, but the real mass unit defined for what I learned to know as "the English system", was a slug, which is the mass which gets an acceleration of 1 ft/s^2 when subjected to a force of 1 lb. This translates to something like 14.6 kg.
Now, coming from Vancouver into Washington State on I-5, I remember seeing a sign that said "Speed limit 88 km/h". Which was correct and appropriate at the time and place, however, my car still had MPH on its speedometer; if I were trying to make it say 88, I'd be an even more interesting object for the Washington State Highway Patrol, what with having Californian plates...
As for speculations on why the US is not going metric yet or even soon: I remember having seen quarts of milk marked as 0.946 liters. Now, when presented with numbers like 0.946, as opposed to nice integers like 1, what will most people do? What would you do?
Threaded pipe dimensions in inches were based on the internal diameter at some point, just to make things even more interesting. Thus, a so-called 1/2" pipe actually has an external diameter of approximately 20 mm, which translates to somewhat more than 3/4". All the common Pipe Thread sizes are this way. There has been some attempt at metricising these, at least within Scandinavia, instead of referring to terms like 1/2" or 3/4" pipe threads, terms like R15 and R20 have been seen instead. That seems to be neither here nor there.
Just to confuse the matter more, in the 1970s, it was common to use metric sizes of threaded copper pipe, which had external diameters in sizes approximating common fractions of inches: 13mm = 1/2", 16mm = 5/8" and 19mm = 3/4" just to mention some of them. These appearently were all threaded with 1mm pitch threads.
Later, these were replaced by true metric pipe sizes with compression fittings or capillary solder fittings. Now the sizes changed again, common ones are 8, 10, 12, 15, 18, 22, and 28 mm. And of course, one needed compression fittings made for 16mm and 19mm also, so as to fit the older pipes...
That's Europe. What I have seen in the US are the commonly found so-called 1/2" copper pipes with solder fittings, this is about 16mm (5/8") in diameter, so I guess they are still using internal diameter measurements. Similarly, the so-called 3/4" pipes appear to have about 21mm outside diameter.
I guess the easiest way to turn these into metric sizes would be to redefine them as 16mm and 21mm and leave it at that. At least the traditional inch-units pipe thread sizes are roughly the same everywhere!
I have seen sections of water-slides where the water flow actually goes uphill for shorter distances. Then there is the everyday action where water flows upwards inside a pipe. Except we're so used to this, so making a display of it doesn't prove interesting.
Still, this does look really cool even though it is a trompe l'oeil.
A pound of prevention vs a ton of cure
on
Hijacking .NET
·
· Score: 1
The example is great -- Dan shows you how he used "hijacking" with a collection of private members to develop a FileAccessControlList class that can be used to manipulate ACL's on Windows files. This is a piece of functionality that is not included with the.NET Framework, but developers have a need for all the time. To write the code from scratch would take days, including translating Windows API declarations to C# or another.NET language and poring over MSDN documentation. As it turns out, all the pieces are in the Framework -- they're just not public.
As has been noted, this remains useable until someone from MS changes the internal implementation and the application no longer can find the proper codes. Then the can of worms is open, and it becomes time to walk the long route of translating the Windows API etc.
Which process reminds me of the bad old days of 16-bit Windows, where useful implementations of such things as dealing with files or directories had to be done via Dos3Call( ) and assembly. At least that was documented, but it was far from pleasant.
Perhaps MS has a way of receiving feedback from developers so that they can extend the API in some durable manner?
Slashdot Mirror
The big problem seems to be that the concentration isn't on traffic even with hands-off versions of mobile phones. True enough, there is not that gross inattentiveness associated with reading or writing text-messages, or other non-telecomms activities like applying makeup or reading the newspaper. Still, the concentration isn't where it ought to be during phone calls, I have experienced this myself, being on "autopilot" whilst talking. Enough to keep the vehicle following the road; but at the end of the conversation I realized I could not remember anything of what I had passed, even obvious things like small towns and intersections.
On the other hand, this idea of being able to quickly get commands across to various in-car systems seems exciting. Being able to turn on a music selection with a flick of the wrist certainly is vastly better than an in-car entertainment system full of pushbuttons. I got one of these here, and I never am able to work it unless the car is stationary.
Unfortunately, I am not sure if this really works, and there still is the matter of having to go and put it into the post -- the fireplace is not so far away and appears to me to be an easier choice.
It is the younger crowd who currently has the most problems with stuff not working under one or the other of Windows ME, Windows 2000, and Windows XP. Throwing WINE on several varieties of Linux into this fray will not really help...
However, designing things in C++ and doing it properly is damn tough; many designs may seem easy to begin with, but then run into trouble with things like multiple inheritance from related parents, or simply that encapsulation is difficult because of the need for exposing the inner workings of classes... STL fixes some of this at the expense of code bloat -- it is easy to produce executables tens of megabytes in size.
Another problem with C++ which has been bothering me, and I would presume, the developers of Peekabooty, is the tendency towards static compilation and inclusion of everything. I looked at the source files here, and the sheer number of include-files compared to source files indicate that this probably does not compile quickly.
There is a way around this, if the application can be divided into several major and fairly independent components which then are compiled and linked as a number of dynamical libraries (.DLLs on Windows, .so on Linux and Unix). Now, with proper design, recompiling the whole lot is not necessary for smaller changes within one of the parts where no changes in this part has taken place. The trick here is encapsulation: do not let code in any one part know about any of the internal structure of code in any other part.
Or a capacitor or battery recovering after a heavy load has been disconnected. This phenomenon is fairly well known to people doing electronic design, it may not be so well-known to the public at large, and there is definitely a big "gee-whiz" effect to it.
One good reference I know of is this article by Robert A. Pease.
Nah ... it's more like "what a cute penguin!"
Jon Lech Johanson was acquitted on charges of having made it possible to extract information from DVD, which as it turned out, he had the rights to do as long as he had paid for the right to watch what is on these DVDs. The relevant part of Norwegian law involved originally had to do with reading other peoples letters.
Since then, the prosecutors have appealed and will have the case tried again in the next higher level court, Lagmannsretten. They cannot press any additional or different charges, the question will still be if it is legal to break into one's properly licensed DVDs.
However, although the charges were initiated by a record companies association, this still was properly handled in a court of law, not through some kind of Internet vigilantism as is being discussed here.
2. In this case, the evidence from the black box did not by itself decide the case. The speed limit was 30 MPH, he said he was going 60 MPH, the investigator estimated 98 MPH and the EDR indicated 114 MPH. Now, 60, 98, or 114 in a residential 30 zone is reckless driving anyways. All this proved was that he was lying,
3. There was no problems with unreasonable search, in as much as the judge had issued a search warrant for this information.
4. The problem is with automated prosecution, which is what traffic-cameras are, and some say this could be turned into. Combined with GPS and tables of speed limits and such.... Seems this enormous focus on speed to the detriment of other dangerous behavior is caused because speed is easy to measure. I do not for a second believe that we will be any safer with people going 30 MPH, behaving like zombies. Just because the speed limit is 30.
This is far too focused on speed limits, making the assumption that the speed limit is always identical to the safe or optimal speed. I don't think I would want to take advantage of the +15 MPH bonus past a school at any rate....
A geothermal power plant could conceivably be made in a similar way, but on a larger scale.
However, you don't have to live close to any volcano for this to work. The heat is there in the underground everywhere.
Certainly, some kind of reversible heat pump which can do double duty as an airconditioner during the summer would be very useful.
In the entry on Hacker Personality, ESR tells about how he managed to remember the 477 pages of the TeX-book in 4 days. By itself this is quite impressive.
However, I cannot help but get the impression of someone bragging of themselves. Such personal anecdotes do not really belong in a reference work. And I am not really sure about whether this is a good example of what hackers do. To me, their main trait is that they create, rather than memorize, things.
One might argue that one never should call oneself a hacker, but this appears to be OK once the title has been bestowed by others.
However, I do hope that the code and associated comments do not look like this or some of the other examples I have seen around here. That has less to do with this whole damn SCO debacle, than with the code quality in general.
i++; already tells anyone in the know that i gets incremented by one, there is no need for a comment explaning this fact! Any comment at this level, if necessary at all, should be telling us something about the reason for this incrementing, if this was not already obvious from context. Comments repeating the C statement in English is a waste of space.
This kind of commenting is a strong indication that the author of the code did a less-than-excellent job.
I'm all for that.
Otherwise I think a picture of a trashcan with the legend "This is not a trashcan" would do nicely as a logo.
To the extent this isn't moot, insofar as whoever signs this NDA and sees the disputed source code, cannot say anything about what he has seen. Then, what is up with this partial source? Why isn't SCO wanting to show all of it?
Let us now assume that someone will be sufficiently bold and/or daft so as to actually go ahead and sign this NDA, and thus get to see this fabled source code.
SCO shows some part of the code, it is anybody's guess what or how much it will be, but there will be some nevertheless. There are two possible outcomes:
Either the code seen is discovered to be infringed, and SCO has a case, although whoever saw this cannot say so, upon his head be it.
Or the code is not infringed. The professional who has seen the code still may not tell, but this time there's really nothing to say either: some other code in there could still be infringed and the only conclusion is that time has been wasted.
Either way, this comes out slightly less than useful. No wonder not many have bothered.
I have seen the English terms "ice sheet" and "continental glacier" for this.
I'd be more concerned about current capacity and even power loss, since the usual CAT5 (as seen in the pictures) is only 24 AWG in size.
The RJ45-connectors at the ends are not high-current either, I have seen numbers in the order of 1A per connector. Even connecting wires in parallell limits you to 4A total (4 wires each way, for 1A each), and the PC power supply used is certainly able to deliver more current than this. Then there is the potential for miswiring and plugging the 12V cable into a laptop network port, which doesn't sound too healthy for either device.
My estimate is that these connectors will become fried before the cable itself once something tries to draw too much current.
Ordinary lamp cord or speaker cable (2*0.75 mm^2 should be readily available) would be a better choice for this application.
mv: cannot stat `zig': No such file or directory
$C0 ... I read that as 192 dollars. Upping the ante as it were?
The next question to ask would be about the timing of this: Which specific functions and features of the kernel are under fire here? And when were these put into the kernel?
And finally, isn't SCO becoming engaged in barratry here?
Now I have turned off unwanted popups...
The weight pound corresponds to the weight of a mass of 0.454 kg. The pound as a unit is thus really a force unit, with the same dimension as the SI unit Newton. So 1 lb = 0.454 kg*9.81 m/s^2 = 4.45374 N.
1 Pound-mass would thus be 0.454 kg, but the real mass unit defined for what I learned to know as "the English system", was a slug, which is the mass which gets an acceleration of 1 ft/s^2 when subjected to a force of 1 lb. This translates to something like 14.6 kg.
As for speculations on why the US is not going metric yet or even soon: I remember having seen quarts of milk marked as 0.946 liters. Now, when presented with numbers like 0.946, as opposed to nice integers like 1, what will most people do? What would you do?
Just to confuse the matter more, in the 1970s, it was common to use metric sizes of threaded copper pipe, which had external diameters in sizes approximating common fractions of inches: 13mm = 1/2", 16mm = 5/8" and 19mm = 3/4" just to mention some of them. These appearently were all threaded with 1mm pitch threads.
Later, these were replaced by true metric pipe sizes with compression fittings or capillary solder fittings. Now the sizes changed again, common ones are 8, 10, 12, 15, 18, 22, and 28 mm. And of course, one needed compression fittings made for 16mm and 19mm also, so as to fit the older pipes...
That's Europe. What I have seen in the US are the commonly found so-called 1/2" copper pipes with solder fittings, this is about 16mm (5/8") in diameter, so I guess they are still using internal diameter measurements. Similarly, the so-called 3/4" pipes appear to have about 21mm outside diameter.
I guess the easiest way to turn these into metric sizes would be to redefine them as 16mm and 21mm and leave it at that. At least the traditional inch-units pipe thread sizes are roughly the same everywhere!
Still, this does look really cool even though it is a trompe l'oeil.
As has been noted, this remains useable until someone from MS changes the internal implementation and the application no longer can find the proper codes. Then the can of worms is open, and it becomes time to walk the long route of translating the Windows API etc.
Which process reminds me of the bad old days of 16-bit Windows, where useful implementations of such things as dealing with files or directories had to be done via Dos3Call( ) and assembly. At least that was documented, but it was far from pleasant.
Perhaps MS has a way of receiving feedback from developers so that they can extend the API in some durable manner?