Follow Slashdot blog updates by subscribing to our blog RSS feed


Forgot your password?

Comment If I'm understanding, consider hard or bind mount (Score 1) 151

So the source is NOT a symlink. You want the destination to be a symlink, and you want it to copy from src/a/file to destination/b/somewhere/ file ? So the file contents up up somewhere totally different than where they are on the source, based on a previously existing symlink on the destination?

If I'm understanding you correctly, you can probably achieve the same goal by trading the symlink for either a hard link or a bind mount. If the symlink points to a directory, use a bind mount instead. If the symlink points to a plain file, consider a hard link.

Comment Continued due to filter (Score 1) 128

Originally, the protocol was designed to be able to have fixtures talk back to the controller, without a request from the controller first. That's why the standard specifies a five-pin connector - one pair for data from the controller, one pair for data back from fixtures, and a ground. The exact protocol for fixture-to-controller communication wasn't established, but the standard said there should be a pair of wires for that, so that a later version could define the specifics.

Unfortunately people didn't follow the protocol specification. American manufacturers use a three-pin connectors, the same connectors as audio cables. European manufacturers used the other pair of wires for all sorts of different things.

The other reason the protocol required a five-pin connector was to avoid exactly what the American manufacturers did - having the DMX connector match the audio connector. That makes it very easy, when quickly running dozens of cables before a show, to accidentally connect an audio device to the lighting network or vice-versa. When a DMX fixture is attached to a mic cable with 48V phantom power for the mic, it can destroy the fixture. The DMX chip is designed to accept up to 12 volts, not the 48 volts that some microphones take. Conversely, accidentally connecting a lighting console to a passive microphone can ruin the mic. Mics are designed to output millivolts at 2Khz sine wave, they aren't designed to be fed 12V at 250Khz square wave. If manufacturers followed the standard, it wouldn't be possible to connect DMX and microphones together, because they are supposed to have different connectors.

Similarly, using microphone cable rather than DMX cable is a common cause of unreliable DMX control. Mic cables are designed to Max out at 2Khz and can have significant capacitance. DMX operates at 250Khz and needs cables with acceptably low capacitance.

Ignore the following. The Slashdot lameness filter is tripping on this post because it I used the same words multiple times. Based on gzip, it looks for repetition. Repeated characters, words, or phrases compress well and could indicate a silly post such as ascii arts with lots of spaces. To get around this stupidness I have to add random words to the post which will reduce how well it compresses.

Comment Starting to do that now (RDM). Why 5 pin cable (Score 1) 128

The parent meant "replies". He's asking about having a stage lighting fixture report back when it has finished moving to the position.

DMX equipment is starting to implement that now. It's an enhancement to DMX called Remote Device Management. It's backward compatible with older DMX fixtures, but not older splitters. RDM allows two kinds of communication from fixtures to the controller. First, discovery. Rather than programming in all of your fixtures, your controller can query "which fixtures are available?" and automatically load the profiles for those models of fixture. Secondly, the controller can send a data request to the fixture and the fixture can respond. So "are you done moving to the new position yet?", "Yes I am.". Fixtures can't initiate communication of their own accord because there is only one data line, and the controller is sending on that line until it relinquishes the line to a fixture.

Comment Expenses are a function of number of drives (Score 1) 151

> Further, I'd argue that I doubt most cloud storage companies list "disk storage" as their primary expense

40TB drives would mean the cloud providers need 90% fewer servers. A tenth as many servers means the datacenter can be 1/10th the size. 90% fewer servers means 90% less tech time of employees going around swapping out bad drives, running cables to new servers, etc. Basically ALL the costs other than marketing and internet bandwidth are a function of the number of drives.

Looking at it another way, if a provider is currently using 4TB drives, switching to 40TB would mean they could have 10 times as many customers in the same datacenter, on the same servers, for the same cost. So yes, most of their costs are directly proportional to how many disks they have spinning.

> I'd similarly argue that even if being able to quadruple storage capacities per 3.5" bay did save them a bunch of money, that they would be unlikely to pass that cost along to customers.

There is in fact competition in the cloud storage market. A lot of competition. So much competition that until recently, major companies were willing to lose money on every customer in order to get more customers (they planned to start making money after the fast growth of the industry began to slow). Cloud storage companies absolutely are busting their ass to give customers the best service they can at the lowest price. They want the business, so they're offering the lowest price they can.

Amazon is of course the premium brand in the space. What they offer their customers is being the *best*, not the *cheapest*. Amazon's cloud has so many useful features added now that the documentation is well over a thousand pages. They give customers "the best bang for the buck" by constantly adding more bang, for the same buck. To that end, Amazon is spending over a billion dollars a month on R&D to constantly improve their products.

Comment man rsync. Three different options to combine (Score 1) 151

Rsync can do pretty much whatever you want regarding symlinks. There are three different command line options. Since symlinks may point outside of the directory you're copying, and may be either relative paths or absolute paths, the "right" behavior is situation dependent. Rsync lets you choose what is right for your situation.

Comment PWM signal spec vs actual (Score 4, Informative) 128

A sensor that outputs a PWM signal, or something that accepts it (such as a servo) has a specified allowable range and curve that it COULD use, and an actual range that it DOES use.

Servo controllers nominally output pulses between 1ms (zero position) and 2ms (full rotation). Actual servo models don't exactly conform to this "standard", so you tune your control to the specific model of servo.

Analogously, the DMX protocol standard says that the BREAK is signaled by a pulse of AT LEAST 88 microseconds (and up to one second). Many controllers fail to read the spec carefully try to output exactly 88 microseconds, sometimes falling a bit short. If you program your DMX to work according to the standard, and test it with truly conforming peers, it'll fail to work with the many DMX items that don't quite conform, or are borderline, sometimes falling a couple microseconds short. To have compatibility with "almost compliant" neighbors, DMX outputs can output a 92 microsecond break, and receivers can accept a 84 microsecond break.

I suspect that's what happened here. The third-party parts ALMOST matched the Apple parts. Maybe they were barely complaint to the spec while the Apple parts were well within spec, or maybe the third-party parts were almost compliant. Either way, they didn't work quite the same, so customers saw failures. Apple adjusted it to work within the parameters of the third-party parts.

I highly suspect if you tested MAF sensor or O2 sensor speced with an output range of "up to 0-5V", you'd find some model's actual range is 0.2-4.5V, while another model's actual range might be 0.3-4.7V. Firmware tuned for the first, the OEM model, wouldn't work quite work as well with the second one - even though they both have "0-5V output".

Comment Thanks for that. Still true, though (Score 1) 204

Thanks for that interesting bit of information.

I tried to include a few words in my post to hint I wasn't saying that Fortran was the FIRST high-level language, or necessarily the first practical one, or the maybe the first widely used high level language. It was an example of an early high-level language that was part of a revolution in the field. C compilers weren't the first to do any optimization, and SQL wasn't the first declarative language. As you said, modern C compilers rewrite the code in ways that would have been unimaginable in Fortran's heyday.

> > With C, we got optimizing compilers that totally rewrite the specification

> We didn't.

Technically, we did. With this paycheck, I got gas. I got gas. With my last paycheck, I also got gas. With my paycheck a year ago, I got gas. Still it's true that "with this paycheck, I got gas" ;)

Am I being pedantic? Of course. That's my job. I'm a programmer. Ccompiler->provides_optimizer == true.

Comment That's called a compiler. Fortran 1957 (Score 5, Insightful) 204

> the humans are no longer coders, they will instead be writing specifications for the code

Humans wrote computer code until 1957. In 1957, it became possible to instead write a specification for what the code should DO, writing that specification in a language called Fortran. Then the Fortran compiler wrote the actual machine code.

In 1972 or thereabouts, another high-level specification language came out, called C. With C, we got optimizing compilers that totally rewrite the specification, doing things in a different order, entirely skipping steps that don't end up affecting the result, etc. The optimizing C compiler (ex gcc) writes machine code that ends up with the same result as the specification, but may get there in a totally different way.

In the late 1970s, a new kind of specification language came out. Instead of the programmer saying "generate code to do this, then that, then this", with declarative programming the programming simply specifies the end result:. "All the values must be changed to their inverse", or "output the mean, median, and maximum salary". These are specifications you can declare using the SQL language. We also use declarative specifications to say "all level one headings should end up centered on the page" or "end up with however many thumbnails in each row as will fit". We use CSS to declare these specifications. The systems then figure out the intermediate code and machine code to make that happen.

The future you suggest has been here for 60 years. Most programmers don't write executable machine code and haven't for many years. We write specifications for the compilers, interpreters, and query optimizers that then generate code that's used to generate code which is interpreted by microcode which is run by the CPU.

Heck, since the mid-1970s it hasn't even been NECESSARY for humans to write the compilers. Specify a language and yacc will generate a compiler for it.

Comment Let me know when computers worry about being repla (Score 2) 221

A lot of people worry about being replaced by machines. That's been a concern for a significant portion of the population, since at least the 1600s. What actually gets tossed aside and replaced by a new machine, every few years, is old machines. Yet machines never worry about being replaced. Indeed they don't worry about anything, or have any concept of self at all. Let me know when machines start worrying about being replaced by Machine 2.0 and that's when I'll be worried.

Comment Re:All energy use ends up 100% heat (Score 1) 130

> Not sure what this has to do with the environmental cost in heat of Google's activities.

Well if you're concerned about the environmental impact of generating heat (a reasonable concern), would it not be useful to be able to measure and compare the amount of heat generated? Rather than the obvious approach of measuring heat by temperature rise email etc, is it not simpler to remember that heat out = energy in?

Comment Of you want to avoid Android. More Linux (Debian) (Score 1) 182

The only reasons I can think of, based on the older version I've used, is if you have your own reasons to avoid Android, or you want to run Ubuntu or Debian userland on your phone.

Android seems to do fine on phones - it works well enough that most devices sold in the last few years are Android phones. Obviously some people would prefer an alternative, other than Apple iOS.

Comment It's Linux. Terminal plus a web browser (Score 1) 182

> Is there a viable pocket-sized, battery-powered server that one could carry in order to use "a terminal and a web browser" with a Chromebook?

It's Linux. A terminal is the native interface. What makes it a Chromebook is that rather than a standard server-side install of Linux (no GUI) or standard desktop install (lots of GUI shit I don't use anyway), it has a web browser a couple other things in a small, very efficient GUI. No GUI for partitioning hard drives, no pre-installed solitaire game. Which is fine for me, I don't partition drives in a GUI anyway.

Then you asked if browsing the web works without an internet connection? Huh? No, I don't do a lot of web browsing work without WiFi.

If you want to, you can install as much as you want of the Ubuntu or Debian userland on top of the ChromeOS-provided kernel. I've not seen any need. My work as a programmer / hacker basically uses a text editor in the terminal, ssh, and a browser.

People who have never tried a Chromebook like to say things like "they are for dummies who don't know anything about computers. A power user would never use one.". One guy I've spoken to, whom I consider to be a power user, had this to say about his new Chromebook:

"suspect I'll make this my primary laptop. I tend to like my laptops slightly smaller, but I think I can lug around this 1.5kg monster"

Maybe someone thinks that guy, Linus Torvalds, is a newbie, and doesn't understand the needs of power users like themselves. Okay, fine, lug around something that weighs three times as much and takes six times longer to boot if you want. Linus and I can look at kernel patches on our Chromebooks.

Slashdot Top Deals

A right is not what someone gives you; it's what no one can take from you. -- Ramsey Clark