Slashdot is powered by your submissions, so send in your scoop


Forgot your password?

Comment It's probably not one person. (Score 5, Informative) 538

The problem is that there are so many people that just a typo will do it. This is why big email aggregators are a bad idea (there are reasons why they are a good idea, of course, or they wouldn't exist, but this is one of the reasons why they aren't).

Unfortunately there is no way to prevent these--there's no test that will reveal them as errors.

Comment work-flow fungibility porn (Score 1) 208

I didn't set out to screed at this length. Shit happens. It might at first look appear to be a bramble patch. Appearances are deceiving.

Every word here is as deliberate as accidental off-the-cuff could possibly be. I suppose I could open up every second snarky entry on TV just listing all the rhetorical devices employed within (should my browser permit this).

However, I spent my wad in the composition and don't feeling like going back over it with a grooming rake. Colour me slovenly. Yes, Dragon Killers Wear Black, but not while actually killing dragons.


I have three displays, so I have three FF tab bars on my working desktop. The vast majority of my windows are full screen. I use middle mouse on the title bar (push to back) to rotate through multiple windows on one screen. I rarely have more than three windows per screen.

In addition, I have a bunch of desktops. Stray tabs from half-completed research topics get grouped together into a new window, which is titled with FireTitle. Then the window itself gets fired off to an alternate desktop. I find that my tab bars become annoying with more than 10 tabs, unproductive at 20 tabs, and almost unusable at 30 tabs (unless my work process is extremely stack oriented, and they all tear down again in LIFO order).

Sometimes a work process starts out LIFO, but then you realize that you're cross-referencing tabs on the same FF window that are far apart. Crossing the phase boundary from a stack-based workflow to a heap-based workflow with more than a dozen tabs open is usually what triggers forking a new window and a mark-and-sweep GC into a named tabs-for-later window, immediately "niced" onto a different desktop).

Now we need to get into why bookmarks suck.

You see, there used to be this technology called a "book", subtype: comprehensive reference work, subsubtype: warts and everything.

People talk about code smells. I'm more likely to talk about documentation smells. A super common documentation smell these days is "let's not even mention the possibility of not-yet-implemented, but super obvious feature that completes the conceptual paradigm". You know, the kind of software which discusses the fabulous cosine feature on their home page, mentions the related feature sin as a footnote in some appendix, and the tan feature not at all, anywhere, ever (maybe the bowels of an associated bug tracker as a feature request, largely snowed under by discussion of "do we REALLY need this" scrum-brainrot feature triage).

A scrummer might think, well, sin is sufficient, anything more would be feature creep. And there is some logic in that, as viewed by anyone who hoped that all Java floating point primitives would be bit-identical across all machine architectures, forever.

But it turns out that floating point is nasty, in the same way that managing memory is nasty, so nasty that we often abstract memory management right out of the software specification (some specifications are just too hard).

sin(x) equals cos(pi/2 - x) only for extremely high quality values of pi.

tan(x)=sin(x)/cos(x) only for a Taylor series expansion of sin(x) with enough precision to complicate memory management .

I'm just using this as a hyperbolic example of skin-deep identities.

Another example: if you've got copy and delete, do you really need move? (If you've previously abstracted memory management right out of the specification, you might struggle to answer "yes".)

What reference book technology used to do is have a little paragraph near the front of a relevant chapter which declared that for the purpose of this application, you do have a complete set of sin/cos/tan, but you don't have a complete set of copy/delete/move (some composition required).

There's a systemic reason why the official online documentation goes to code-smell "obnoxious silence". Because Stack Overflow. Remember how we all loved the way PHP defined its formal semantics by long user-contributed discussion pages? Well, now we've abstracted a formal declaration of scope right out of most project's official purview.

Which is often great. But it leads to this little problem that it now takes five to ten Stack Overflow tabs to add up to a single useful paragraph from original technology reference book.

I played with SaltStack for a couple of weeks earlier this year. Lacking a strong conceptual overview to orient myself, I soon had window after window after window filled with partially-digested Stack Overflow threads, while I played Great Detective. (SaltStack is particularly obnoxious in the tone of its official meta-documentation having zero on-the-ground caloric content.) In addition, Python lives in about tenth place on my proficient languages list. So I soon had window upon window of Python idiom Rosetta stones (more like Rosetta pebbles).

Think about it. I'm not going to adapt my workflow to use FUCKING BOOKMARKS for this kind of cruft.

I realize that the GC generation is not as well equipped to reason formally about object lifetimes as my own, but let's go there, anyway.

What is the likely object lifetime of these steaming piles of Stack Overflow tea leaves and crunchy expanses of Python-idiom pink gravel?

Depends on the halting problem.

My screams will halt the moment some damn syntactic frob actually works. (How to find out what SaltStack just attempted to do before puking its guts out ... yet another simmering thicket of thin-gruel tab soup).

And we all know about the Great Straight Line of pulling your hair out over sprawling ecosystems one doesn't yet comprehend at any deep level: we invented cheap, cheap, cheap git branches to handle this. Cheap as in 1600 branches = piece of cake. Cheap as in 1600 ZFS datasets (or 1600 ZFS snapshots) = piece of cake.

But, browser tabs, my God! now we're spending real money.

It actually happens, with fractal logic, that many of my tab flurries soon resolve themselves and I punt them en masse, while other tab flurries stubbornly persist, until at the end of the week I consign them to my how the "hell could this still not work?" queue. (I'm sure I had one of those after using FreeNAS to set up PXE boot to load a test OS onto a crashbox that was hard-locking at the first BIOS taste of EFI-formatted thumb drives. I finally got it to work with a few bizarre contortions that I never completely managed to smooth over.)

Here's the thing. Bookmarks were invented in an era when books were useful consolidations of warts-and-everything full disclosure. This no longer exists, in the main.

For most of my disposable tabs, there's simply not enough there there to serialize from my working set into a formal bookmarks folder.

I was reading the other day about how Python doesn't have many scopes (after eliminating braces, who knew?) "Well, if your loop index names start to collide, consider breaking your function up into smaller pieces." and "in practice, I don't find that I trip over this problem all that much" (sounds a bit to my ear like the hoary C++ programmer canonically afflicted with Stockholm syndrome). It was funny, because I had just watched a video where Stroustrup (or Meyers?) talked about the dysfunction of the C++ standardization process, pointing out that inside Microsoft, Visual Studio C++ needed to be able to compile functions containing 40,000 statements (everyone else was implied to have their own very special pickle sauce), which makes it hard for the big players to all jump onto the same tooling boat. C++ is exactly the language that doesn't say "40000 statements in one function—you must be mad".

And now we have a computer science profession divided into two camps: (A) be conservative in what you refuse, and considerate in what you demand; and (B) let's just add the cure for insanity into the global water supply.

Turns out, it's far too easy to play "father knows best" at arm's length.

You have this large code base that grew organically, with less than optimal foresight (picture, if you will, the original Mozilla).

You realize in sober retrospect that some important things pulled off onto a rusty side track Destination Ugly and you want to Do the Right Thing and fix this. But some helpful fairy whispered into your ear "the root of all evil is concurrent refactoring" so you set out with your best Bilbo Baggins walking stick (adventuresome, yet oh-so-Shire all the way down to your squishable bone marrow).

You've Got a Plan. You're going to corral the worst of the worst of the ugliness into one place, where it can reside with the "deprecated" ankle bracelet until you can finally tip it into the ocean once and for all (FreeNAS Corral combined all these steps into a single, grand yowl but that's another story.)

But think about it: you're basically compressing Pure Evil until the ankle bracelet fits the potty-mouthed pea-hating princess.

And somehow, by a painful litany of degrees—you had to be there to fully understand—you end up with a Mordor() function containing 40000 statements (in Microsoft's case, this likely stems from the original smelting conditions).

Of course, you could refactor Mordor(), as a side project to Securing Gondor. Which pretty soon (consult any corpse in the Dead Marsh) will spin off into a side side project refactoring Nine Lords.

Here's the thing. Python is So Beautiful (By Design) that you always exist at depth 0 in the Refactor of Eden, and the moment you stray but a little, the Phial of Galadriel will illuminate your immediate safe return to happy Hobbiton.

"What concurrent refactor?" ask the cute, innocent cherubs of strange Uncle Bilbo.

They do say that youth and beauty are wasted on the young. To which Postel's law is the One True permanent testament.

Stubbornly, I clad myself in my no-limits-anywhere ZFS mithril armour, which boldly proclaims: thou shalt never be caught with your pants down in Concurrent Refactor at The Worst Possible Moment instigated by an Ungenerous Tool.

Only this: How to increase MNAMELEN on FreeBSD 4-stable

This raises two questions: Why do i386 and alpha have different limits? And shouldn't 80 (or even 72) characters be enough for everybody?

For the first question: The value of MNAMELEN is chosen so that the size of the statfs structure is exactly 256 bytes, so it will align nicely on memory page boundaries. The alpha platform is a 64-bit architecture, so some elements of the statfs structure take more space. Therefore, MNAMELEN is a bit smaller in order to compensate for that, so that the overall size stays 256 bytes.

Uh, oh. I've got a bad feeling about this.

But still, shouldn't 80 (or 72) characters be more than enough? In the above example, the longest filesystem node takes 14 characters.

Sure sounds like the Root of All Evil about to clear a giant phlegm wodge.

For most needs, it is indeed enough, but there are cases where you run into trouble.

At this point, the author goes off onto a not-entirely-contrived narrative of pain, entirely unrelated to running nested ZFS jails, with nested delegation (e.g. Poudriere inside iocage).

The patch described on this page will increase the limit to 208 characters (i386) or 200 characters (alpha), respectively. BUT: It will break binary compatibility for some programs. Not for all, but for some. Notably, you'll have to recompile any non-standard shells such as bash and zsh, Tools that do things to your file systems such as backup programs (e.g. Amanda), and probably a few other things. On the bright side, you will be able to continue using your old Netscape 4.x binary. ;-)

To be more exact: All programs that use the statfs(), fstatfs or fhstatfs() system calls will break, i.e. they will crash with signal 11 (SIGSEGV). You will have to recompile them from source. If the source code is not available, you've got a problem.

Of course, everything you do, you do it on your own risk. If it blows up your machine, don't blame me. You have been warned. If you're not familiar with compiling kernels and with the "make world" process, don't do it.

Your mission, should you choose to accept this, is to Imagine the Tabs. Should one choose to walk this path, they would surely breed like fucking tribbles: I spit on your Mordor() and raise you a non-standard sizeof(statfs_t).

So sure, fine, for all you comfortable Hobbits snug in your bed, use bookmarks.

But for myself, I've got some serious necromancing to do. Any necromancer in my neck of Mirkwood dons ten bandoliers at the first sniff of ominously contorted spider silk.

No doubt, in post-enlightenment Fangorn, everyone now subscribes to Closet Organizzar Monthly. Well, suit yourselves, but please remove your grubby Martha Stewart fingers from my frictionless bandolier bangles.

Comment Re:Obvious Hollywood shill is obvious (Score 1) 191

Sorry to hear that. Sounds like Denver is seriously behind the curve.

Out of interest, am I the the only one who doesn't care that much about the trailers? It gives me a chance to find my seat, and maybe skip to the bathroom before the feature presentation, and occasionally (admittedly, only sometimes) I get to find out something is coming up I actually want to watch. Dunkirk for example was on during the Wonder Woman trailer, I'd not heard of it before that.

Comment Re:Obvious Hollywood shill is obvious (Score 1) 191

I don't know if you've been to a (mainstream, chain, in a moderately normal part of the country) cinema lately but they're seriously doing a lot to address your concerns, with large, comfortable, reclining seats, cup holders, and digital projection if they can't support 70mm or IMAX.

The improvement in seat quality has come at a cost that I've noticed most cinemas in my area now have so little capacity - bigger seats with more legroom means fewer seats - that they have had to resort to assigned seating for more popular movies. My wife and I watched Wonder Woman during the afternoon and there were only five spots in the theater where we could sit together.

Which, I guess, leaves snacks, but I've yet to come across a cinema that'll search your bag, or, you know, you could forgo them and eat before or after you've seen the film.

I've seen various ups and downs in the movie industry. I remember how terrible theaters were in the 1970s when my father took me to see The Jungle Book, and a little later, Star Wars, watching the former on a screen that probably wasn't more than 2-3x bigger than the TV I have today. Things slightly improved in the 1980s, largely because all of a sudden the cinemas had money to spend on long needed renovations, but by the mid-2000s we were back to dirty cinemas with cramped seats and, in one cinema I went to, the smell of pee.

But we seem to be back to the cinemas doing something about it and revamping their theaters. I don't know how long this will last, but I like it.

Comment Re:In & out (Score 1) 285

If you like fast startup but you like not wasting electricity, I suggest you look into putting your system into suspend or hibernate mode. I haven't seen the grub prompt on my desktop or servers for a while and even my laptop has an uptime measured in weeks. Who cares how fast it can startup services?!

(On the other hand, since using systemd on one of my systems, I've had to reboot that machine way more than I ever had to before. It reminds me of Windows now. I can see why fast boot times are an important feature of systemd!)

Comment Re:No, train (Score 1) 88

You can remove the timbers from a boat and replace them, that doesn't mean you can't name the boat! But for what it's worth, trains aren't broken up as often as you might think - typically once a train is on a route it stays the same consist for years. If the train is a DMU or EMU, then it usually stays as that consist for its entire life.

The other problem with your assumption is that the word "train" can differ depending on context. If I say "I'm taking the train to New York tonight", and you say "Oh, which one?", am I providing the most obvious answer if I say "Well, the one lead by locomotive 40126", or "The 6.23, I guess I better be at the station by quarter past six!"

Trains are named according to multiple criteria: a train can be a physical item, such as a trainset or just "Any train with this locomotive"; but a train can refer to the marketing of a specific timetabled route: for example, the US has lots of "named trains" like the Silver Star and the Texas Eagle.

I hope this makes sense,

Comment Re:Better than random (Score 1) 93

Random guessing is 50% in this case, as the skill being measured is the skill in differentiating between the control group and the study group.


Overall, link-weights (that is, correlations) in a supervoxel-level functional network were the most discriminative features, achieving 74.0% classification accuracy compared to 51.6% chance level

(I also thought it was possible that the chance level was 50%, but I didn't want to go out on a limb, so I fired up my link viewer.)

The statistical methodology was too complex for me to digest into any directly interpretable model, leaving it hard to assay. I don't think this test would be applied to a normal population. It might have some diagnostic utility distinguishing schizophrenia from bipolar, which is apparently difficult to accomplish in the clinical setting.

Comment Re: Never going to happen (Score 1) 307

Maintenance should be significantly lower than the NEC/Acela Express, given the primary issue with the latter is that it's 150 years old and showing it. Ridership should be similar to the combination of the Acela Express and Northeast Regional with similar fares.

The NEC is profitable BTW. Just saying. It's the reason why Texas Central and All Aboard Florida are doing their things.

Comment Re: This sounds like nothing (Score 1) 307

A high flying passenger jet isn't really a good comparison for a number of reasons: it's a container of higher pressure air (it's relatively easy and easy on materials to contain 1 atmosphere of pressure - think about how you'd get a latex balloon and some wire to contain one atmosphere at 50,000 feet. Now think about how you'd use the same materials to keep the same amount of air at one atmosphere 30 feet below the surface of the ocean...);

Another problem is that passenger jets don't try to keep a perfect one bar of pressure when they're flying at high altitudes, which is why divers are told not to fly within 24 hours of a dive.

And a final problem is that, really, the pressure at 50,000 feet is about 0.1 atmospheres, whereas the pressure in a hyperloop tube will be a significant fraction of that. That said, building a container to protect 10% of an atmosphere from 100% outside probably isn't substantially different from building one to protect 1% of an atmosphere, it requires compressive strength only around 10% higher.

It's a fairly massive engineering challenge to keep 400 miles of tubing big enough to contain a Tesla Model 3 at a pressure of 1% (or even 10%) of an atmosphere. I'm not saying it's impossible, but... it's certainly going to be expensive and/or will leak rather a lot requiring substantial energy expenditures just to maintain the vacuum.

I'm personally more bothered about the fact it'll be a horrible traveling experience, but the engineering does seem a little off the wall from where I'm standing.

Comment Atlantis emits the batfish signal (Score 1) 59

There are many of these announcements where I just file the URL in my searchable wiki, to see if the day ever arrives where the technology is mentioned in a comprehensible, second context.

Cost of comprehending the original market-speak .GT. received utility modulo a not-improbable gaping ocean rift.


Atlantis just called. STOP SENDING IoT! You've nearly buckled the entire plate, and our mermaids are all becoming discouraged and refusing to tail dig.

Comment Re:Baloney (Score 2) 281

As phones became more powerful, applications were using more battery. So people were all over the manual ways to preserve battery life. Software development on the relatively new phone OSes matured, and thus was able to move on to tackle "later" generation features like power-saving and efficiency (and the hardware became more efficient too, like the BT and GPS chipsets.)

Users usually lag behind stuff like this, and end up with habits of things they used to have to do long after the problem has been largely addressed in software optimization and feature work.

Slashdot Top Deals

Adding features does not necessarily increase functionality -- it just makes the manuals thicker.