1amzave

If the servers in question happen to be on the list of supported hardware, quite possibly. (I don't know of any up-to-date online list, but running `source setup` in the root of the source tree will print it.)

"The wise man speaks because he has something to say. The fool speaks because he has to say something."

(See also: comments by idlewords, pkw2017.)

Really? If you're going to do that, it seems like you might as well just merge all those users into a single account anyway, considering how trivial it would be for any one of them to execute arbitrary code as any other.

Until I can, as an unprivileged user, watch my own process's syscalls with dtruss, it's not an alternative to strace. Requiring root is a major hindrance.

Also (more specifically to one of the given examples), enabling `-A` on all your ssh invocations likewise seems like a pretty bad idea.

When using little-endian, you imagine that the bits are in little-endian order, to be consistent with the bytes, and then everything is nice and consistent.

But isn't that kind of at odds with how shifting works? (i.e. that a left shift moves towards the "bigger" bits and a right shift moves toward the "smaller" ones.) Perhaps for a Hebrew or Arabic speaker this all works out nicely, but for those of us accustomed to progressing from left to right it seems a bit backwards...

According to their documented "Current Limitations" (https://developer.apple.com/library/prerelease/content/docum...):

Case Sensitivity: Filenames are currently case-sensitive only.

First thought: they have seen the light!

A moment later: wait...they consider this a "limitation", and it's only "currently" the case. So maybe they're going to perpetuate the brain-damage anyway.

Sigh.

Fails to mention what is in my opinion the most devious, subtle potential pitfall with `set -e`: assigning (or even just a bare evaluation of) an arithmetic zero. `foo=0` won't do anything surprising, but `let foo=0` will return 1, and thus abort your script if you're not careful.

Also, as an alternative to the proposed `set +e; ...; set -e` wrapper for retrieving the exit status of something expected to exit non-zero (generally cleaner in my opinion, if slightly "clever"):

    retval=0
    count=$(grep -c some-string some-file) || retval=$?

While this is a legitimate complaint, it also applies (though in fewer ways) to C. How do you parse this?

  (x)(y);

I don't think the problems with that advice are singular. Perhaps the most ultimately-relevant is that looping exactly N times without a "ceremonial" counter is really only very rarely useful. Truly, how often do you see the canonical `for (i = 0; i < N; i++)` pattern in C with no references to `i` anywhere in the loop body? (Hint: if there are any, it's not "ceremonial".) Blindly repeating the exact same sequence of code just isn't something you want to do very often.

To address the issue of "okay, in what languages could we do this anyway?": taken in full mathematical generality, such a capability would necessarily require bignum support, which cuts down your options significantly. I'm not sure if that was actually the intent, but if we instead accept the limitation of "up to some largeish power of two", constructing a macro to do this "directly" in C would also be quite easy. So...(shrug)

Perhaps I should clarify -- I am (happily) not involved in web development, and from the developer's side browsers may very well be in pretty good shape these days (I wouldn't really know).

But speaking purely as a user, I think the statement "browsers suck, like really bad" still holds very true.

For example, "back in the day" browsers sucked, like really bad.

I'm reminded of Mitch Hedberg: "I used to do drugs. I still do, but I used to too."

If I'm reading N1256 right (not sure how far back it actually dates, but that's a C standard draft dated 2007), section 6.7.2.3 also explicitly allows a trailing comma in that context as well, so if such a compiler exists its makers should get with the program, so to speak.

So why the quad i7, 32GB RAM, and 480GB SSD?

It's right there in your quote:

...a web browser...

I'm reminded of an excellent quote from Bertrand Russell:

"Everything is vague to a degree you do not realize till you have tried to make it precise."

Why are they using MIPS as a metric for comparing integer CPU performance? When you're looking at two different compiler backends targeting two (very) different ISAs, it seems pretty thoroughly uninformative.

See other reply: https://news.ycombinator.com/item?id=10363281

Realistically it's not going to be that simple though. The filesystem proper (e.g. ZFS) may verify checksums when pulling in data from a storage device, but then it's going to sit in the page cache for some arbitrarily long time. Whether by faulty DRAM, cosmic rays, or writes through stray pointers, that's a potentially major source of vulnerability to data corruption. There's of course a mirror-image vulnerability on the write path: you write into the page cache, and if something borks your data between that point and when it actually gets written back to storage, you end up persisting it (quite arguably worse, if perhaps less likely due to dirty data usually getting flushed within a reasonably short time).

Basically, the filesystem isn't the end point, and thus simply isn't positioned to really provide "end-to-end" protection.

I think a reasonable argument could be made that if it's in the filesystem it's not end-to-end.

I don't get what the word "libre" has with the "great free software nomenclature war" or why that would make people avoid LibreOffice.

Personally, I avoid "office suites" in general like the plague and hence don't have much of a horse in this race, but "LibreOffice" has always struck me as a name that rolls off the tongue in approximately the way a refrigerator would roll off a flatbed truck.

Is that really the definitive metric though? Seems like you'd want to compare overall program-text size between equivalent binaries for x86[-64] and $otherarch (i.e. x86 may be able to get away with fewer of those ~same-size instructions due to each of them doing slightly more on average).

Neat...and on a somewhat similar note (bash enable -f hacks), some bash FUSE bindings I wrote a few years back: https://github.com/zevweiss/booze

I initially wrote it basically just for giggles, but was rather pleased a few months ago when I realized I could use it for something I actually needed, and it was just the right thing (presenting a mount point that acted as a view of the differences between two rsnapshot-style hard-link trees -- only took a few dozen lines of very simple code).

Looks neat, though I can't help but wonder if you'd be better off with DRBD (run it disconnected by default, then just connect and let it sync naturally when you feel like it).

I haven't actually used it myself and am certainly willing to believe it's immature, but how do you mean it has "little in common with RCU"? Comparing personnel between that library and this set of people --> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... there's certainly at least some authorship in common...

Yes, this essentially just a form of RCU. Note however that RCU isn't just for the kernel anymore though: http://urcu.so/

So what happens when you find yourself running on a CPU that wasn't in your initial affinity mask?

Also, the "sleep for 1 ms" approach used in `init()` looks wrong -- if `sched_setaffinity()` doesn't guarantee that the calling task has been migrated to one of the target CPUs on return (which I suspect it does), I don't think sleeping for a millisecond is going to change anything.

Possible unintended side-effect: `taskset -p` might have "interesting" effects on your process.

Sure -- but my point was merely in regard to the (mis)use of the word "pure" here. Avoiding calling out to external executables and remaining purely within the shell itself is also frequently a good way to improve performance (sometimes quite dramatically), so being aware of the difference is worthwhile.

(Also, /dev/tcp isn't a filesystem, just a simulation of one constructed purely within bash itself, so it wouldn't in fact depend on anything but the relevant networking syscalls.)

Arguably not pure bash, in that it calls out to external executables. I'm pretty sure all the head/cut/tr invocations could be easily replaced by appropriate parameter expansions though, and the `read` builtin could probably supplant `dd`, so it should be doable.

After getting more and more tired of Apple's generally obnoxious behavior over the last few years I'm wondering which straw will be the last for me before doing exactly that. I'm pretty seriously considering wiping OSX off my MBP and running some variety of Linux on it at this point, though regrettably I might still be forced to consider them for future hardware purchases on account of the fact that I don't think I've ever encountered a non-Apple laptop that seemed worthwhile (in terms of general construction and build quality).