Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re: Why not? (Score 2) 372

What gives you the very incorrect idea that the 'old' clode is single-threaded? IBM mainframes have supported multi-processing since 1965. Current models have up to 120 CPs in one image. And as for performance - there you are WAY out in left field. Many COBOL programs involve decimal operations, and in COBOL that translates to HARDWARE decimal operations. If you think you are going to get anywhere NEAR that performace with Python (snort), I'll have what you're smoking.

Comment Re:COBOL is still quite valid for use... (Score 1) 372

Well yeah, it is the job of an optimizing compiler to produce the most efficient code for a particular architecture. Of course, the compiler can only do that if the language supports a particular type of data. If the language doesn't support a particular datatype, then you can't do anything at all with that type of data. Which is why the gmplib has all the important stuff written in assembler (not C) - because C does not support decimal operations.

The question is not whether or not you can do a certain operation in a given language. You can do damn near anything in any language. The question is can you do it efficiently. The 'C' implementation is probably the least inefficient, but it is still worse than native support. The Java and Python implementations are ridiculous wasters of cycles.

Also 'INTELS' decimal128???? Seriously?

Comment Re:COBOL is still quite valid for use... (Score 1) 372

Huh? You can do binary integer and floating point arithmetic in any of those languages without any libraries, classes, or modules. You can only do decimal operations in those languages by either converting the decimal numbers to binary, operating on them, and converting back or by calling something written in a different language. Hiding those things elsewhere does not magically mean that the language supports decimal.

Comment Re:COBOL is still quite valid for use... (Score 1) 372

If Java, Python, and C support decimal operations, then why are a class, a module, or a library required? COBOL, on the other hand, directly supports decimal numbers. Two fixed point numbers can be read in, then operated on directly, then written out with no conversions. And the operations (add, subtract, multiply, divide, format, etc) are done with a single machine instruction (on a mainframe).

Comment Re:Knowledgable (Score 1) 102

For someone who says others are unable to follow a conversation, you certainly show yourself to be unable to do so.

You are talking about stability during a discharge cycle. Of course that is important, and nobody is saying anything that even remotely contradicts that. This is the 'stable voltage range' he is refering to.

But he was aked about the FAILURE mode of the batteries. And in answer to that he said there is a narrow WINDOW which will produce that stable voltage range. The WINDOW is refering to the CHARGE voltages that are required in order for the battery to produce that stable range on discharge. There is only a narrow window of charge voltages which will produce the desired output.

By reading ALL of his answers, you can see that the problem is that, on every cycle, more of a film builds up on the anode. This film interferes with the charging process (ie. less voltage is reaching the electrolyte). As long as the voltage is still in that window, stable output results. After a certain number of cycles there is enough film that the voltage reaching the electrolyte is OUTSIDE that window, and now the battery can no longer produce that stable voltage. The cell has FAILED.

And the solution he provides to the problem is to prevent the build-up of film by plating the anode, which can't be done with the liquid electrolytes. He is in no way saying the problem is the stable voltage range, he is saying that in order to keep the DESIRABLE stable voltage range, you must stay in the window by preventing the film on the anode.

Comment Re:Relevant XKCD (Score 1) 102

Telsa's pre-sales run to about 400K cars. 17.55 million new cars were sold in the US in 2016. So, if all of those pre-sales turn into actual sales, that is about 2% of car sales. Once. Is there any indication that they would sell ANOTHER 400K cars the next year, or will everyone who wants one already have one? That remains to be seen.

You have provided zero evidence that 'manufacturers are adopting EVs at a much faster pace...'. Have they announced the conversion of factories to EVs away from ICEs? Have they announced new factories that are capable of building more than 2% of their cars by 2020 (only THREE years away)?

Comment Re:Knowledgable (Score 1) 102

He did not say anything about a stable output voltage. He said the electrolytes have a small window for a stable voltage range. The most likely means that if you charge the electrolyte to (for instance) 3.4 volts it will be stable, but you can't charge it to more than 3.5 volts or less than 3.3 volts. That is a small stable voltage range REGARDLESS of how well it holds that charge or delivers that voltage on discharge. And that is important, because as the internal resistance increases (due to anode decay), the voltage reaching the electrolyte decreases. Once the voltage reaching the electrolyte falls below 3.3 volts the battery does not store it. Which is exactly what we see with lithium batteries.

Comment Re:Relevant XKCD (Score 2) 102

What he is doing is cherry-picking. Yes, there have been cases where 'experts' drastically underestimated the impact something would have. However, there are just as many cases where they over-estimated the impact something would have. SSTs were going to drastically change air travel, except they didn't. Segways were going to change urban transport forever, except they didn't. The difference between over- and under-estimation is that the things that were under-estimated are around to remind us of the error, while the things that were over-estimated aren't.

Cars were immediately seen as better than horses by most people. They pretty much sold themselves. Manufacturers didn't have to convince people to buy A car, they had the convince people to buy THEIR car. Same with cell phones.

Does the average driver immediately see EVs as superior to ICE? About the only reason they would is price of fuel. Environmental concerns are important, but almost always take a back seat to economics at the individual level.

Yes, auto-makers may be projecting 1~2% sales by 2020, but the vast majority of them are rushing to bring EV's to market in the next few years. Their actions speak louder than their words.

This statement really doesn't make sense. 2020 IS 'the next few years'. Having 1-2% of your cars be EVs is better than having 0% of your cars be EVs and losing those customers to a competitor which is what will happen if they don't rush to bring out EVs. Their actions are in no way 'speaking louder than their words'.

Comment Re:Knowledgable (Score 1) 102

In your effort to appear superior to the guy who invented that battery, you managed to prove his point. The reason that batteries have the characteristic you pointed out is BECAUSE lithium has a narrow stable VOLTAGE range. They are either at that narrow range, or they are dead. Once the anode deteriorates sufficiently (due to the lack of plating), the resistance increases until the lithium no longer reaches that voltage during a charge, and the battery is dead. If lithium had a wide range (as you stated), then it could charge to 3V, or 2V, or 1V. It would no longer be working one day and dead the next, it would gradually put out less and less voltage.

Comment Re:Is mass production a science goal? (Score 1) 102

You are talking about completely different disciplines. Someone who is an expert in the chemistry of a battery may not know anything about the issues involved in actually manufacturing said battery. Someone who is an expert at manufacturing may not know anything about the chemistry involved.

Your 'kick the can' scenario doesn't have anything to do with the above. That happens because it is enormously expensive, in both time and money, to get a design change into hardware. The farther you move down that chain, the quicker and less expensive it becomes. Somewhere in that chain is the 'sweet spot' for any given problem. Some problems are best fixed in hardware, some are best fixed in documentation, and most are best fixed somewhere in between. There is no one-size-fits-all always right answer.

Comment Re:Knowledgable (Score 3, Informative) 102

He mentioned the anode in several of the answers. He said the solution to the anode problem is using the electrolyte to plate the anode with lithium. He said that the organic, flammable, liquid electrolytes can't be used to plate the anode because dendrites form, leading to shorts and fires. About the only thing he did not specifically state was that as the anode deteriorates the voltage goes down until it is out of the electrolytes stable range, and then the battery is dead.

So, yes, the organic flammable liquid electrolyte is precisely why the batteries suddenly go dead.

Comment Re:This is really funny stuff! (Score 1) 300

Wow, talk about missing the point.

Of course you can't make guarantees, but what you CAN do is quantify both the COSTS and the BENEFITS of doing something. Something with a low cost/benefit ratio is probably worth doing. Something with a high ratio is not. In your motorcycle example, we can look at history to make a determination: protected riders fare far better than unprotected riders, so the benefit is great. The cost is not absurd, so wearing protection makes sense.

So we can also apply this analysis to this problem. One the one hand, we have the current systems. What is their track record of dealing with change?

Went from running on 24, to 31, to 64 bit addressing hardware
Went from data stored on punch cards and tapes to online DASD
Went from standalone systems, to networked with SNA, to networked with TCP/IP
Went from green-screen UI only available to bank employees to mobile apps available to all customers
Went from all batch-processing to mostly on-line
Went from account information only being available via a mailed monthly statement to being available 24 hours a day, updated in real-time
Etc, etc

Now, what is the supposed 'risk' with these systems? The pure FUD that 'there may be a change they won't be able to deal with'. Such as what, exactly?

On the other hand, we have the 'new and improved' systems. Exactly what is THEIR track record? Exactly WHAT change are the existing systems going to be unable to cope with, but the new systems will be able to cope with? Any examples at all?

It seems that the 'benefits' portion of the equation is sadly lacking (except for the FUD factor, of course)

Then there is the COST portion of the equation. The track record here is not good. There have been many public and spectacular failures doing what you suggest, all at enormous cost.

So what we see is a gigantic cost, and a benefit of 'maybe this' and 'maybe that'. When your cost portion is that large, your benefit portion better be larger, as in as close to a guarantee as you can get. You have not provided anything even close to that.

Comment Re:Why do airlines overbook? (Score 1) 575

It depends on why you didn't show up. Most common reason would be a missed connection. In that case, they get you to your destination so there is no reason to refund anything.

If you arrive at the airport late most airlines will get you on a later flight.

If you have a refundable ticket and let the airline know you want a refund (before the flight), you get a refund.

If you have a non-refundable ticket and let the airline know you don't want it, they will let you exchange it for another flight (for a fee)

In no case is there even the slightest hint of fraud. If every case the airline fully intended to get you to your destination, and in every case except the one where you just didn't bother showing up, they will get you to your destination. And that last case is 100% on you.

Comment Re:This is really funny stuff! (Score 1) 300

I never said anything remotely similar to there will be no new requirements. I was merely pointing out that there have been MANY changes already, and the stuff is still working. You, on the other hand want to spread the FUD that 'there may be changes that the COBOL may not respond well to'. Well, can you guarantee that whatever rewrite you do WILL respond well to these as-yet unknown changes? No, you can not. Therefore, what you are suggesting is that organizations spend tons of money and time, and incur enormous risk, to wind up with a system that will not necessarily be any better than what is already there,

I have no idea why you are babbling about SCADA systems and Oracle systems in an article about large financial institutions and COBOL, which are almost exclusively the realm of mainframes and CICS.

Of course the mainframe systems have to trust the data that is fed to them. Do you have some magical new system/language where that is no longer the case? If not, how is rewriting the COBOL code going to actually improve the situation?

Slashdot Top Deals

"They that can give up essential liberty to obtain a little temporary saftey deserve neither liberty not saftey." -- Benjamin Franklin, 1759