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

 



Forgot your password?
typodupeerror
×

Comment Correcting intelligent completions is difficult (Score 4, Interesting) 87

If my completion is predictable, I know what I have to type without looking at the screen.

If it is smart, I must always check if what I want to do is in the completion list.

If it is too smart, it will propose complex completions, that are correct 80% of the time, and look correct 90% of the time at first glance.

The "typos" I make today with smart typing correction in my smart phone look to other people like correct sentences. It's just confusing. No one can guess what I meant to write.

Comment Re: Why is the FS a problem? (Score 0) 424

I've seen them, and I hate them. I hated them from the first time I saw them. Actually, so much that I always (successfully) tried to avoid writing one. I think once I used a template.

Just look at this fuckery. I have to write the PID logic myself? Or I have to copy code? This is bullshit. I don't wan't to do this.

Once I've read a thread about X, and one comment said "If you have a UI, it's not Linux anymore!". Init scripts are for those people...

Comment Re:Why is the FS a problem? (Score 1) 424

Never having to deal with init scripts before, I had to install a custom service on a server. My company was using custom bash scripts to restart processes that die. They also have some wierd mechanism to suspend the restart behavior, and some really bad email reporting. I wrote a systemd script for my service and was quite happy with it. I could even configure sending an email on crash rather easily.

When talking to the sysadmin of our company, it appears to me that he doesn't like systemd, just because it does some things differently compared to as it was before. That's a pretty weak argument.

Comment Re:Why so much animosity? (Score 1) 76

This sounds much like the "If you know how to program, you can pick up any language quickly." kind of thinking. I encounter it often, and I also thought this way right after finishing university. But it's simply not this way. Maybe all imperative languages are alike, yes. And if you know imperative, and OOP you can pick up many languages quickly. You will not learn anything new doing so, though. But if you change paradigm, you will find out that there is much you don't know.

Comment Re:So what (Score 2) 282

Even with the best AI, we need to give it an objective to try to accomplish.

There are some very simple objectives, like "Don't die." or "Replicate.", for which this is not exactly true. Unfortunately these are already very problematic objectives.

Already today you can create dumb agents in evolutional experiments that follow these objectives. And you do not have to implement those objectives. They are intrinsic to (complex) dynamical systems. Systems that change over time. It's not even that you need the physical laws of our universe to spawn evolution. Evolution is an effect that simply exists in every dynamical, i.e., time changing, system. Things that survive and replicate tend to dominate things that don't, because they survive and replicate. Simple, right? You do not have to program things to follow these objectives, they are simply there.

Comment Re:You have to look at the source (Score 1) 456

This is true. Just two days ago I did a medium sized refactoring on a Scala project.It's a personal project, and I started moving some stuff around, and then I did more and more, renaming things, changing method signatures. And right in the middle I thought "Damn, what's this mess I just made? You should have made this one little step at a time.". But I just went on fixing compile errors. And in the end everything worked again, and I was fine. With strong, static typing, you can just make the change you want to make, and then fix all the type errors–and most of the time it will work again. No way this is possible in a dynamically typed language. But then, I probably wouldn't have done this with Python.

Comment Re:That's theory, but in practice? (Score 1) 118

I doubt that the authors of the paper can build a 1eV transistor right now. It can be done in theory. In theory you can also make the irreversible transistor much better.

And now that I skimmed over the article, it says that only 1 meV is theoretically lost per bit. This makes my point even more valid. We can improve current technology to be one million times more efficient before hitting this thermodynamical barrier.

Also, you finish your post with an unsupported statement. It might also be less plausible to shuffle 1000eV wasting 1eV than trying to make 1eV switches directly. And being a bit picky: eV is unit for energy, and not for charge.

Comment That's theory, but in practice? (Score 0) 118

I did not read this article, so I'll just make up some numbers I find plausible.

Somehow we need to equate entropy (or information loss) with energy. The assumption of 1eV per bit is probably ok. One electron, either changing potential of 1V or not.

So by making computations reversible, we could avoid this inevitable 1ev loss if the computation is not reversible. Nice. But if we currently burn 1keV per switch, there is no point talking about this technology right now. Let's shave off another 990eV first. Then we can think about reversibility.

You have to understand that making the computation reversible (not loosing this bit of knowledge) gets you from 1000eV to 999eV. That's premature optimization. And you all know that this is the root of all evil. Though we might keep an eye on it.

Slashdot Top Deals

God doesn't play dice. -- Albert Einstein

Working...