Slashdot Mirror

The real manipulation was the feds on the AIAG.. but TREAD RFID is also quite shockingly real. Why dont you please look at these following links and read all my extracted highlights here in this post:

Goodyear, Michelin and other tire manufacturers are claiming TREAD is the reason they are forced to put in spy RFID transmitter chips in all tires... not whims. A bylaw document addendum for TREAD is merely one strongarm tactic by feds that aided it to be fully adopted. AIAG manipulation was another.

Goodyear RFID tires from TREAD :
SNIPPET QUOTE EXCERPT:
"Tires have to have a unique identification number called a DOT number," he said. "Cars have a vehicle identification number. Under the TREAD Act, carmakers have to associate the unique number on each tire with the VIN of the car it's put on. RFID offers a cheaper way to do that association

web source : http://www.rfidjournal.com/article/articleview/122 3/1/1/

Michelin RFID tires from TREAD :

SNIPPET QUOTE EXCERPT:
"The tire industry faces regulatory pressures from the National Highway Traffic Safety Administration requiring tire companies to monitor pressure and temperature in tires as part of the Tread Act, a much-publicized law passed in 2000 in response to the rollovers of Ford Motor Co.'s Explorers equipped with certain Firestone tires. The Tread Act states that the vehicle identification numbers must correlate with the Department of Transportation's number for the tire."

web source : http://72.14.207.104/search?q=cache:NKrAuVWpXksJ:w ww.internetweek.com/allStories/showArticle.jhtml%3 FarticleID%3D49901229+%2B%22tread+act%22+%2Btires+ %2Brfid&hl=en

Industry and TREAD RFID ..

SNIPPET QUOTE EXCERPT:

"There are no industry-based automotive mandates out there today. Perhaps the only exception to this is the Tire TREAD Act in which RFID is specified as a method of identifying tires supplied to OEMs. The U.S. Congress passed the TREAD (Transportation, Recall, Enhancement, Accountability and Documentation) Act after the Firestone/Ford Explorer issues emerged. The act mandates that carmakers closely track tires from the 2004 model year on, so they can be recalled if there is a problem. "

web source : http://www.zebra.com/id/zebra/na/en/index/rfid/faq s/rfid_considerations_specific_industries.html

Industry abd RFID TREAD :
SNIPPET QUOTE EXCERPT:
"For example, Michelin and Goodyear plan to use RFID to aid their compliance with the Transportation, Recall Enhancement, Accountability and Documentation (TREAD) Act."

web source : http://www.fawcette.com/wss/2003_10/magazine/colum ns/trends/

Notice a theme ? Instead of blaming AIAG these tire companies blame TREAD federal law compliance for the RFID tracking chips in all passenger tires. Read those links, you government shill.

And next, you will start claiming the products dont work well on highways.

Here is a meticulous research PDF paper entitled "Test Report : Single-lane Vehicle identification with UHF RFID"

http://www.ipico.co.za/technology/Whitepapers/Sing le-lane%20EVI%20Test%20Report%2020030618.pdf

And that shows a LOW POWER 4 watt reader at a height of 5.7 meters (18.7 feet) above a passive RFID coil product can read at speeds of 160 km/h for common tollway type RFID. The feds buy >4watt readers and also use better gear.

I love the naysayers.

njyoder you ar wrong! TREAD is real.

Goodyear, Michelin and other tire manufacturers are claiming TREAD is the reason they are forced to put in spy RFID transmitter chips in all tires... not whims. A bylaw document addendum for TREAD is merely one strongarm tactic by feds that aided it to be fully adopted. AIAG manipulation was another.

Goodyear RFID tires from TREAD :
SNIPPET QUOTE EXCERPT:
"Tires have to have a unique identification number called a DOT number," he said. "Cars have a vehicle identification number. Under the TREAD Act, carmakers have to associate the unique number on each tire with the VIN of the car it's put on. RFID offers a cheaper way to do that association

web source : http://www.rfidjournal.com/article/articleview/122 3/1/1/

Michelin RFID tires from TREAD :
SNIPPET QUOTE EXCERPT:
"The tire industry faces regulatory pressures from the National Highway Traffic Safety Administration requiring tire companies to monitor pressure and temperature in tires as part of the Tread Act, a much-publicized law passed in 2000 in response to the rollovers of Ford Motor Co.'s Explorers equipped with certain Firestone tires. The Tread Act states that the vehicle identification numbers must correlate with the Department of Transportation's number for the tire."

web source : http://72.14.207.104/search?q=cache:NKrAuVWpXksJ:w ww.internetweek.com/allStories/showArticle.jhtml%3 FarticleID%3D49901229+%2B%22tread+act%22+%2Btires+ %2Brfid&hl=en

Industry and TREAD RFID ..
SNIPPET QUOTE EXCERPT:

"There are no industry-based automotive mandates out there today. Perhaps the only exception to this is the Tire TREAD Act in which RFID is specified as a method of identifying tires supplied to OEMs. The U.S. Congress passed the TREAD (Transportation, Recall, Enhancement, Accountability and Documentation) Act after the Firestone/Ford Explorer issues emerged. The act mandates that carmakers closely track tires from the 2004 model year on, so they can be recalled if there is a problem. "

web source : http://www.zebra.com/id/zebra/na/en/index/rfid/faq s/rfid_considerations_specific_industries.html

===

SNIPPET QUOTE EXCERPT:
"For example, Michelin and Goodyear plan to use RFID to aid their compliance with the Transportation, Recall Enhancement, Accountability and Documentation (TREAD) Act."

web source : http://www.fawcette.com/wss/2003_10/magazine/colum ns/trends/

You are probably an FBI shill for wanting to FACTUAL INFORMATIVE mod the post to -1 like it was 4 out of five times before... all using the feds shill accounts.

njyoder, If you have a fact to dispute then post your facts! Otherwise read and learn! The feds aready scan car tires on the roads.

Did you even READ this post, did you even read the other? or are you a sock puppet account for the FBI?

As you probably know there are a ton of languages that will compile down to Java bytecode and run on any JVM (e.g. jpython).

So why don't you just grab an OpenSource Java compiler and add a --case-insensitive compile switch?

You could then code merrily in whatever case your caps lock key happened to be set in, and it would run on anybody's JVM.

Or just suck it up and get used to case sensitive programming like the rest of 3 million Java developers

---
JaVA hOSTing on a lINUX vps

Hi Everyone:

I'll probably try to get around to replying to many of your posts directly (will, the really useful ones at least :) ), but I wanted to take a moment to thank everyone for their input thus far, and reply to some of the recurring ideas and themes.

The jSyncManager has, in fact, been around for quite a while. I started working on it back in 1997. It eventually became my thesis project. Shortly after graduating from Brock University, I joined up with IBM, working at their Toronto Software Lab.

At this time, the project was closed source (a bit of a mistake on my part). As with many big software firms, I had to sing the restrictive "IBM owns everything you develop" employment contract, which made continued work on the jSyncManager difficult (this was at a time when IBM was still formulating its rules for employees participating in Open Source projects).

As an in-between solution, I entered into an agreement with my local legal department to offer the jSyncManager through IBM in a co-copyrighted manner, where I retained the copyright to everything as it existed prior to joining IBM. Due to some problems IBM had with the name, it was changed to IBM ManplatoSync for Java. My original agreement was that the project was to be released as Open Source under the IBM Public License -- but while I kept working on the project (in my own time mind you, and for no money), the IBM lawyers kept passing the buck, and permission to actually release the project source to the public was never granted.

After leaving IBM early last year, I decided to dig up the pre-IBM source, fix it up somewhat, and make the jSyncManager Open Source myself.

In the time I've been working on the project, we've had several mentions in the press (Chapter 11 of O'Reilly's "Java Cookbook" mentions the jSyncManager in passing, the May 2000 issue of Java Pro reviewed us against Palm's own CDK for Java (very favourably I might add :) ), and we got a mention in "Assistants", an Australian publication for Chartered Accountants), and I've spoke about the jSyncManager at a few conferences (Wrox Wireless 2001 in Amsterdam, WarpStock 2001 in Toronto, and CASCON 2001 (sponsored by IBM and the National Research council of Canada), also in Toronto). Unfortunately, all of these happened before I released the jSyncManager as Open Source. Things since have been pretty dry (even though IMO we have a much better product now!).

So, we're in a good position to attract attention and funding -- we're a mature project that is rock-solid (we do have to work on our initial setup a bit, as getting end-users to grab all of the necessary third-party libraries we rely upon is curruntly an issue, but it's something we'll work on by creating installer versions that include the necessary libraries once we get closer to our next GA release), and has been received favourably in several communities.

(I do want to note that when I wrote up my story submission, I was quite aware of the potential marketing implications of getting such a story on Slashdot, as some readers here have observed. This wasn't really my intention, which is why I'm trying to ask generic questions to see what ideas every has -- I'm hoping other projects can benifit from this discussion as well. Getting our website /.'ed is an unintended side benifit :) ).

Something I've learned in the six years I've been developing the jSyncManager is that while I'm an excellent coder (well, at least I think so ;) ), and a good project administrator, and while I don't mind blowing my own horn somewhat, I know that I am _not_ a sales/m

I remember during the Team OS/2 vs. ClubWin wars on USENET there was a drive within Microsoft to rename the position to "Technical Advocate". It failed because some product managers (not project managers) argued that "advocate" wasn't an agressive enough term. Sigh.

By and large though, Microsoft evangelists tend to be nice people (like Scoble, who used to organize the Fawcette industry conferences for a long time). Much different from sales drones and even most enterprise support reps.

Yes. And you could have done the same rearchitecting of the code in C, and had even better performance.

On the two re-architecture projects I've worked on, we considered implementing our improved design in C++ (no classes in C, so that wasn't an option). However, we found that it would have been cost prohibitive, due to portability and maintence costs, and the limitations of the STL vs the Java 2 JDK. So, yeah, we _could_ have done it in C/C++, but we wouldn't be selling it now, we'd still be writing it.

Yeah, you can get better Java performance if you create all your objects in a huge pool and then just hand around references to the thing. It's also a pain in the ass.

Object pools are a bad idea in Java, but I can't even count the number of C/C++ programmers who I've heard say thats what's needed to "fix" Java. I'll say it again...If you take the time to learn how Java is supposed to work, you'll be 10 times more productive and create a product of equal (or better) quality.

Uh, huh. As evidenced by all those high quality horizontal Java apps. Oh, wait.

Considering Java has 54% of the software development market, I'd say there's probably more Java out there than you think. It's just mostly on the backend, so you don't see it (unless you bother to look).

Is a for() loop in Java faster than in C? No. But if raw performance was the only consideration, we'd all be writing in assembler. Development costs, maintainence costs, deployment costs, portability, security....in all these other respects, Java beats C/C++ hands down.

The main thesis of Tim Bray's original post was that he didn't like having to choose between either storing all his data in memory (i.e. DOM) or using a callbacks(i.e. SAX) when processing XML. The problem with this kind of thinking is that although it may have been true two or three years ago that the only way to process XML was via DOM or SAX this is no longer the case.

There are more classes of APIs supported on multiple platforms for processing XML such as pull-based APIs and cursor based APIs which are represented by the System.Xml.XmlReader and System.Xml.XPath.XPathNavigator in the .NET Framework. Similar APIs exist in the Java world as well as Python from what I've heard. This is besides the current push in some quarters for programming languages that natively process XML (i.e. intrinsicly understand an XML datamodel or datatype).

Tim Bray's original problem was that he doesn't have a pull-based API for XML parsing in Perl. I pointed out in my kuro5hin diary how the pseudo code he showed as being his ideal for processing XML already exists in C# and .NET Framework. This article on XML.com points to other people who also point out that such pull-based APIs for processing XML are available on other platforms and languages as well.

The main thesis of Tim Bray's original post was that he didn't like having to choose between either storing all his data in memory (i.e. DOM) or using a callbacks(i.e. SAX) when processing XML. The problem with this kind of thinking is that although it may have been true two or three years ago that the only way to process XML was via DOM or SAX this is no longer the case.

There are more classes of APIs supported on multiple platforms for processing XML such as pull-based APIs and cursor based APIs which are represented by the System.Xml.XmlReader and System.Xml.XPath.XPathNavigator in the .NET Framework. Similar APIs exist in the Java world as well as Python from what I've heard. This is besides the current push in some quarters for programming languages that natively process XML (i.e. intrinsicly understand an XML datamodel or datatype).

Tim Bray's original problem was that he doesn't have a pull-based API for XML parsing in Perl. I pointed out in my kuro5hin diary how the pseudo code he showed as being his ideal for processing XML already exists in C# and .NET Framework. This article on XML.com points to other people who also point out that such pull-based APIs for processing XML are available on other platforms and languages as well.

If I understand it correctly, the author is lamenting that neither of the standard ways of parsing XML in a scripting language fit the straightforward model of scanning for something relevant and then acting upon it, where the two models are: 1) read in whole file and make a tree (take sup too much memory, is slow, etc.); or 2) use a callback interface.

The style of perl script he was seeking was a simple loop model:
while () {
next if /ignorable/;
if (/thing-one/) { ... }
elsif (/thing-two/) { ... }
...
}
To me the thing that distinguishes this the most from the provided XML parsing interfaces is that it has a minimal amount of state.

So isn't what is needed a corresponding structure to the while () above that iterates over the tree-nodes of the XML-encoded data structure, in a depth-first preorder traversal (to avoid having to build the whole tree first)? One could imagine a parser object that scans through the XML file returning nodes (and their parent history) while maintaining an absolute minimum of state. If one wanted to build an in-memory representation of a subtree given a node, then one can always do so when one finds the node one wants.

Such an interface wouldn't be good for integrity verification or the like, but for the sort of application the author was talking about, it would seem ideal. Much less flexible than the normal models, sure, but much easier to work with when the problem fits this sort of description. Perhaps I'm underestimating the difficulty of the task, but it doesn't sound too hard to write, given that it is doing so much less than the fully-featured XML parsing interfaces.

The other problem is the awkwardness of the use of XML in O-O languages such as addressed in the article linked-to by Tim Bray in his article. Though I haven't used this particular program, this seems to be the problem that FleXML is trying to address. When you don't need all of the flexibility that XML can provide, but instead have a fixed schema that your XML-representation follows, why not have your parser automatically built to read it? People have used lex/flex for scanning text files for decades --- in these days of XML Schema, it should be even easier. If FleXML lives up to its promise, it will be. Has anyone here used FleXML and are willing to comment on how well it addresses these sorts of problems?

I read about it about a year ago in Java Pro.

Here's an article

And here
And here

Hope that helps.

There was a good article about Naked Objects in java pro last April. It's an interesting idea I think, maybe not for final-products but allowing end-users to see something early on so they can get a better idea as to what they really need in the end product (maybe feature x isn't really that important).

Very robust and well thought out language. Yes, Yes, I know blah blah blah M$ this and M$ that. But ya know what? I could give a flying crap about everyone's predisposition against Microsoft.

I'm not sure Microsoft should be thanked for the greatness of the C# language on it's own, which I'm sure most of us agree is the best thing of .NET -- not it's Windows-specific libraries.

Thank Anders Hejlsberg, chief architect of the C# language, instead.

While I'm on the topic...

Anders Hejlsberg interviewed about C# #1
Anders Hejlsberg interviewed about C# #2

Pretty interesting, where he discuss the design goals of C#, how satisfied he is with what C# became, etc.

I think we're going to be pretty successful with ASP.NET and ADO.NET, which are really well abstracted. Windows Forms is probably going to be the trickiest one because we might have to do some emulation of the Win32 layer. But we're positive we can solve the problems that remain.

http://www.fawcette.com/dotnetmag/2002_01/magazine /columns/jfinsel/

"Tech-workers" is such a broad category, according to this JavaPro article, Java programmers are earning more than ever and working less to get it.

However, I'm a Java programmer and I don't have a job so you can't rely on everything you read.

-Russ

Our 2002 career survey sampled Java programmers' work and compensation and compared it against geography and gender, education and training. The results--starting with total remuneration--were perhaps surprising, given what we've come to expect from a squeezed economy and lowered expectations. Last year, the programmers we surveyed in the United States earned on average $83,000, but this year the average total compensation--salary and benefits--of our sample was $93,500--11% more than last year.

This book is the first of its kind, covering topics that haven't been explored this directly anywhere. It does a remarkable job, covering not just the tools but the philosophy behind good unit tests and frequent, automated builds...." ... ... "The philosophy behind this material is modern and forward thinking. ... (The book has the ) potential to make you a better programmer and better able to deliver higher-quality code on a shorter timeline. "

--Claude Duguay

Check out the full review at http://www.fawcette.com/javapro/2002_04/magazine/d epartments/bookreviews/default.asp

Take a look at 10 Tips for Great .NET Programming. Tip #10 states that:

The .NET Framework exposes classes that let you compile code in a specified language. These classes live in the System.CodeDom.Compiler namespace. This code snippet shows how to obtain an in-memory running instance of the C# compiler:(...sample code follows)

This seems to allow one to write a compiler/installer solution on the fly.

Gokhan Altinoren