Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Comment: Re: just put a motor on the elevator itself (Score 1) 233

by arth1 (#48926067) Attached to: Engineers Develop 'Ultrarope' For World's Highest Elevator

Elevator brakes are one of the most elegant solutions known to man, and perhaps more crucial to the continued popularity of the cabled elevator. The brake is held open by spring tension generated by the interaction of the elevator and the cable. If the cable gets cut, the brake engages. That's it. Any other type of elevator would need a more complicated break system. Detection of fault conditions would be a separate action that triggers the brakes. That means delays, and the possibility of errors. It is practically impossible for a properly built cable elevator to plummet. You cannot say the same for any cableless concept design. One of the simplest ideas in legal liability is that if you opt to do something the more dangerous way, you're liable. You must have very good grounds to justify the risk.

You miss that in a pinion or cog driven elevator with the motors in the building, there is no need for emergency brakes - being stationary is the default state. Only if a motor moves the cart along will it actually move - up or down.
To me, that seems like far less risks than having a system where you need emergency brakes for safety, no matter how elegant.

And this system is in use in many assembly lines. The motors are stationary, and the carts won't move unless driven. And while most are horizontal systems, there are vertical ones too. Boxes with holes or pinions on the side are lifted or lowered by cogwheels, and there is no possibility of them falling. They can reach quite high speeds too, unlike the typical self-driven pinion-and-rack lifts that you see on boatyards and libraries.

Comment: Re: just put a motor on the elevator itself (Score 1) 233

by arth1 (#48920975) Attached to: Engineers Develop 'Ultrarope' For World's Highest Elevator

The motor on an elevator like Noah is suggesting would have to provide enough force to counteract the entire weight of the elevator + payload + motor + friction, which is at least an order of magnitude more than a traditional elevator.

Not necessarily, no. Put fixed motors on the shaft walls, not in the elevator, and put pinions on the outside walls or corners of the elevator. The only extra weight would be of the elevator itself, less the weight of the hanging cable which elevators today have to move, and less the weight of the braking system, which would now be in the building, not the elevator.
And the much smaller building mounted motors can recuperate some of the energy whenever the elevator is descending.
Because each motor would only have to lift the elevator for a small distance before the next motor takes over, I imagine that higher speeds can also be attained, with less energy expenditure.

Comment: Re:Coding vs. literacy (Score 1) 199

by arth1 (#48915523) Attached to: Why Coding Is Not the New Literacy

You seem to have taken this very personal, resorting to personal insults for a post that had nothing whatsoever to do with you.
I suggest you change the relationship and automatically score mod my posts so you don't see them, because I will keep on ranting about things I feel like ranting about, out of the blue, without taking your feelings and opinions into consideration. They're worth exactly nothing to me - sorry.

Comment: Re:Coding vs. literacy (Score 1) 199

by arth1 (#48914105) Attached to: Why Coding Is Not the New Literacy

What you talking about is spending 80% of total effort on 20% of the features of the product. Often these features are not even readily visible to anyone.

Apps not freezing or crashing or becoming unusable by the customers aren't features.
They're side effects of programmers (among other things) actually understanding the underlying system and what happens when you poke the beast.

Comment: Re:First Sale (Score 1) 453

Exactly right! What a lot of people don't understand is that the First Sale Doctrine is a defense not an offense. In other words, if you buy a copyrighted item, like a book, and resell it, the First Sale Doctrine protects you from getting successfully sued by the copyright holder for doing so. In other words, it is a defense. It does not however, put any obligations on the publisher to provide any support to ensure that these later customers can use the product.

Neither does it give them a right to burn my book.

The problem here is that you don't buy a game. You buy a license to use a game. They revoke the license, which is their right, but by doing so, you are no longer bound by the license terms either, which includes the payment you made. Depending on the jurisdiction, you might have a good case for winning a small courts claim or similar, covering the purchase price and reasonable legal expenses.

Comment: Re:Coding vs. literacy (Score 1) 199

by arth1 (#48911695) Attached to: Why Coding Is Not the New Literacy

I'm not talking about messing with IO requests. I'm talking about understanding what happens when they're issued, whether it's by you or a library you use, so you don't lock up a system for no good reason.
But these days, this is considered "arcane knowledge" and is ignored, in favor of blindly using magic toolkits and libs, and blaming the system for not performing when it's the app that is badly designed out of ignorance.

Comment: Re:yes, programming, like poetry, is not words, un (Score 2) 199

by arth1 (#48911271) Attached to: Why Coding Is Not the New Literacy

I've always thought programming is more like writing POETRY than just being literate

I disagree. You don't hire poets to design a space ship - it may be pretty, but it won't work. You don't hire sci-fi writers either - it may look workable to the masses, but the pesky laws of physics and economics will have their say.

Programming is more like engineering. As in being able to construct something that actually works.
Coding, on the other hand, is more like manufacturing, where you produce something based on what the engineers have come up with.
But too often these days, it's not engineers that came up with it, but bloody poets, and the poor coders have to steal bits and pieces they don't understand from people they have no reason to trust in order to make a workable mess out of it.

 

Comment: Re:Coding vs. literacy (Score 4, Interesting) 199

by arth1 (#48911229) Attached to: Why Coding Is Not the New Literacy

Hmm. If you can't read, you are restricted to looking at pictures. If there is someone to read for you, then you can hear the parts of text they choose to read for you, otherwise you are pretty much restricted to children's picture books. A lot of what happens in the world is simply a mystery to you.

That's happening more and more. I find myself going to web sites looking for manuals and specs, and all they have these days are videos. I don't want videos, I want text, with orders of magnitudes higher information density, searchable and editable.

Dumbing down seems to be across the board. User interfaces, recipes, clothing, handwriting, ability to add and subtract without a cash register or calculator, you name it.

And yes, "coding". Which has taken over for programming. The typical modern "coder" builds houses out of Lego. They may look colorful and shiny, but at the end of the day it's still Lego.

Gone are the days of programmers who actually devised algorithms and discussed them, instead of Googling for something that might be pressured into service. People who would understand what an OS call actually did, instead of treating it as magic. Something as simple as describing what happens behind the scenes when doing an IO request is beyond many newer coders (some of which I work with).
Programmers, they aren't.

We have to start expecting more, and stop rewarding and kowtowing to incompetence.

The Wright Bothers weren't the first to fly. They were just the first not to crash.

Working...