Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment Re:proprietary vs postgres (Score 1) 104

I tried Oracle many years ago... Nothing seemed to work right. I had all kinds of funky failures, things that would not connect, etc. I assumed it was because I was just skim reading the documentation. So I read everything carefully, reinstalled from scratch, checked every last setting, etc. Some problems resolved themselves because the defaults were all wrong, but still nothing really worked. Eventually I resorted to asking for help, and after some time, discovered that the problem was that my server name started with a "U" and there was a bug for servers starting with letters "T-Z" or something like that! Anyone that can code a bug like that should not be allowed near a computer. I uninstalled and installed postgres - never looked back. I just wish I could get the MS folk to give up in SQL Server now...


Comment We need software engineers (Score 5, Insightful) 126

Professional engineers, not self proclaimed ones. Ones that sign on the dotted line taking personal responsibility for the code they write. With self driving cars, robots, drones, etc. we need to be able to hold coders responsible, the same way we hold held civil and mechanical engineers responsible.

Comment Still the jury foreman's fault (Score 1) 69

The real problem in this case, evidenced from post case interviews with the jury foreman, is that despite the majority of the trial being about prior art to invalidate Apple's patents, the jury was so confused that the jury foreman (the only member of the jury with any experience with patents) persuaded the jury that it was not their job to judge the validity of the patents. His reasoning was that since the patent office had granted them they must be valid. This was based on his experience of having a very hard time getting the patent office to accept his patent, because they kept raising prior art.

This was in direct contradiction to the written instructions to the jury, and should have resulted in a mistrial, since the jury foreman brought outside evidence into the discussions. The other important feature is that there is a difference in how patent claims are evaluated by the USPTO and by the courts.


Comment Re:When one fails to learn from history ... (Score 1) 183

Your friend is full of it. Most rubberized asphalt concrete in the western US uses 20% rubber, and that is mostly in the form of rubber granules mixed in. These come directly from recycled tires. So: 1) they are tire rubber - if they were melting then so would the car/truck ties. 2) they are not continuous on the surface, so there would be no continuous layer to slide on. 3) It is impossible for most people to tell if the surface has rubber or not - generally you need a core sample and a microscope. For terminal blends and plastic modifiers, you have to do a chemical analysis of the recovered binder.

Also, rubberized AC has mostly the same noise characteristics as conventional AC. You might be thinking about open-graded asphalt concrete, which is significantly quieter...


Comment Re:Crazy? (Score 1) 183

In the US asphalt concrete is composed of asphalt (or more correctly asphalt cement) and aggregate.

In the rest of the English speaking world asphalt is composed of bitumen and aggregate.

There hasn't been tar in roads for decades (hint: it is highly carcinogenic)


Comment Re:We all owe K&R a lot of money (Score 2) 181

The problem is not how they are licensed (public, open source, whatever). What Oracle claim is that their copyright precludes unlicensed copies - so IEEE could require "posix certification" for all libraries implementing the POSIX API, so they could prevent glibc or any other "libc" from being distributed. That might not be a huge risk for POSIX, because of the IEEE involvement, but there are a lot of APIs out there.


Comment Re:Thermodynamically Impossible (Score 3, Informative) 311

As someone with a PhD in Pavement Engineering, and an active researcher into pavement design, let me say this is a classic case of someone thinking that because something looks simple it is. Pavements are the most complex civil engineering structures to design, because they are the only structures designed to fail in fatigue. My wife showed me their video the other day, and all I could do was laugh. Reading their FAQ now, shows they've never asked an actual pavement engineer for their input (and FHWA funding shows nothing, in fact googling shows that they're not even really being funded by the FHWA research budget but by the Small Business Innovation Research (SBIR) program i.e. this is money to promote small business, the research is a secondary goal).

Just a correction for you though - there is not really an AASHTO testing protocol, that was a one off test done 50s and 60s. Now, most proof testing of these types of innovative designs are done by accelerated pavement testing.

Before we even look at the engineering, look at the cost: the highest cost pavement currently are precast concrete slabs, which are similar in some ways to this idea (except they are 50 times the size). They cost about $3 million per lane mile to install. There are over 8 million lane miles of public road in the US, so their idea in their video of covering all the roads in the US would only cost $24 trillion (or nearly twice the US annual GDP) assuming they could get the cost down to that of concrete... Assuming for the moment that the solar panels themselves are cost neutral, just the cost of the glass and support structures would make this impossible to afford.

From an engineering perspective, you have functional and structural criteria. Functional are skid resistance, spray, noise and light reflectivity. The glass would polish, resulting in low skid resistance at high speed, and bad light reflection. Their textured surface would be OK for low speed skid, but really bad for noise and spray, even with drainage between the panels. Many new pavements have a porous top layer for this. Their paving stone like pattern would be really bad for noise (like block paving). Putting LED lights into pressure sensors for animals would be fun, but probably not reliable, and on roads you have to have systems that are reliable because either drivers can trust them, or they are a waste of time.

Structurally, the fact that they refer to gross vehicle mass is a dead giveaway that they don't know the first thing about pavements... The critical number is wheel load. Their panels look to be an awkward size between an interlocking block paver where the wheel load is spread across several blocks, and a concrete slab. The panels would need to be connected in such a way that they can expand and contract, with sufficient load transfer between panels for the entire surface to act as a continuum. With this size of panel there would a lot of flex at the joints, which would break most materials. Concrete slabs get joined using 1 inch dowel bars... Assuming these were placed on existing pavements, maybe they would work, but my guess is that they would get beat up quickly by highway traffic.

Then there is a question of life cycle assessment. Their "numbers" page shows they also know nothing about this either. They just include the benefits... There is no measure of the system, including manufacture, construction, maintenance, etc. They also don't have albedo measurements, etc...

So, to conclude, I don't think this idea is going anywhere fast. Their first step should be to hire a pavement engineer. Then they need to do some lab testing, then use their $1.7 million for an accelerated pavement test to determine if their design can work as a road, before they do any more messing around with electronics... At least their idea is not as silly as the people who want to put piezoelectric generators into pavements to capture all the "wasted" energy...


Slashdot Top Deals

"The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." -- Richard P. Feynman