caladri

Well, it's possible to make the deduplication work with Glacier, though. Colin's right that you want to phase versions of the whole tar into slower and cheaper storage, but the technical problem of whether blocks are used in newer versions doesn't actually seem to be too much of a problem. You can compute it in a batch for extant tars, and track it for new ones. (And you can keep blocks-of-references always in S3 rather than Glacier, say.) The problem he identifies as most troublesome is what if you see a case where you would want to deduplicate, but the similar block is in Glacier, and so would be a bottleneck for the whole deduplication process. In this case, you could always treat it as a non-match, right? And optionally have some way to track it and then when it gets moved to Glacier either determine whether it was actually a match all along, or just have some duplicate data.

Of course, I don't know how tarsnap names its blocks or stores them, so I don't know how feasible it is to have two blocks with the same name because they had the same hash but there was a byte-by-byte mismatch, or if that's even a problem.

I mean, blocks that have been moved to Glacier because there are no references to them from indices on S3 can be assumed to be less likely to show up in new archives. It's a trade-off, but my experience with deduplication is that it's often not much of a trade-off to get rid of old things even though the magical thinker in me is tempted to think "but what if that chunk happens to show up again somewhere else!?"

I think that iXsystems' support of PC-BSD is something like an attempt to do that, but it seems like they're not doing much workstation stuff these days, whereas previously they were at least trying to do slightly more. PC-BSD is getting a reasonable open source ecosystem and user experience around it, though, such that someone who can handle the business development and hardware side of things would have a rather easier time than someone starting from stock FreeBSD.

Devices being used in a kiosk-like or other setting in which they are mostly not being used by people who would be responsible for activating them?

The filename refers to NCFTA, which might seem in context to be http://www.ncfta.net — perhaps some bit of intel that's widely-traded in NCFTA circles for various uses? I mean, hey, pretty useful if you're tracking down pretty much anything in which an Apple device is used, right?

I'm not sure I see how this is in-keeping with any Unix philosophy I've encountered. "Everything's a file" is good, yes, but this program is needlessly-specific when what it does need not be. This is just a tool for browsing a file hierarchy in which the files happen to be GPG encrypted, right?

Which one thing is this doing and doing well? Merely being command-line and somewhat file-oriented does not make Unix orientation. The utility has numerous sub-commands, many of which are simply wrappers for other commands, like find(1) or tree(1). An encrypted file-system or some other way of encrypting the password hierarchy would seem to be exactly all the value this adds over simply using the extant set of Unix command-line tools. Most of this functionality simply duplicates the shell and cat(1).

It doesn't do one thing and well, it seems to do a small number of very general tasks in needlessly-specialized ways requiring arcane and unfamiliar incantations. The password generation stuff makes a fine stand-alone Unix utility. But git integration in the same program?

This is a front-end which brings with it a considerable number of ideas about policy, rather than simply providing a tool. Most of what it does could be handled much more simply by the filesystem and the extant tools it leverages or reimplements.

Now that we can see what a results page looks like, it seems like something more than a sorted list of numbers might be interesting. I mean, there's not enough data collected at the start to do something very interesting, but a chart and some statistics would be fairly simple and make it much more digestible. As it is, it's just a numberwall.

Alright, so the obvious thing would seem to be to have a pool for HN readers, right?

http://www.salaryshare.me/10ffcd6db9cf188be1a1175de8ff8f3d

Your problem is actually with the organizers. You don't care a bit about random venues except for where organizers of events you are likely to attend decide to use them, I would guess. Therefore, if you have a problem with the venue, you should take it to the organizers, and take it up with them at the time, e.g. by leaving with your student, because wrangling the venue is what they're doing as organizers setting up an event.

Other venues are much more reasonable about this sort of thing. I have a friend who is banned from all Microsoft buildings, including non-Microsoft events hosted by Microsoft. He was informed clearly in writing, and knew the reason for his being banned. That makes Microsoft-operated venues more appealing (on at least this axis) than Yelp ones, since organizers of an event can't be sure that attendees will actually be able to enter. In the Microsoft case, at least a person seemingly knows whether they can attend.

Well, Amazon is making news because we can naively assume by looking at a summary that they're doing it the same way they make money — by working in volume. We can estimate pretty quickly how many people work in Amazon's warehouses, at something in the neighborhood of "an awful lot of people". So it sounds good at a glance. Few people will even notice the details that whittle away the eligible base down to around 0.

If they were giving a paltry reimbursement to everyone who worked in an Amazon warehouse while taking classes, that would add up to something much more significant than the big companies I've worked for that employed people who already felt set-for-life and who could've gotten an advanced degree on the company dime if they felt like it, for example.

Two hours of travel round trip to go to, what, an hour of class? And that's alongside however far one has to drive to work in a day. So maybe you can get away with doing that one day a week? Two? It's going to be a very slow, very miserable slog. Even an hour of travel total, which is probably near the average minimum, is a lot when your days are as packed as Amazon's full-time warehouse employees.

I think when you say that you pretty well reduce the vision of programmer culture in the US. How much cypherpunk influence is there in the wide swaths of programming culture that came out of Web 2.0? And how many cypherpunks have gone on to work for the NSA, DARPA, etc.? I'm not sure the landscape is so very different, and certainly one could tease out a cypherpunk influence in Russia that's much more obvious and profound than that in the United States.

There are many programmer cultures, and even cypherpunk culture is very complicated. There are some very different strains of cypherpunk thought, i.e. the divide between those whose primary mode of action as being exposing the scariest actor around and those whose effort is centered in hiding from the scariest actor around.

Can you expand on "shows its age"? Code entropy doesn't increase as a function of time alone. An ANSI C "Hello, World!" from 1990 doesn't show its age in the context of C today, for example.

Is age an issue in its own right, or is it what informs what you perceive as a poor implementation that precludes the implementation of "modern" features? Also, I wonder if you perceive any possibility that progress might actually occur in the form not of accumulating more features on top of the modern fashionable designs but of starting from an earlier base and pursuing an alternate path of evolution to that of extant runtimes — do you?

For example, is it possible that there is some innovation which could occur on top of C which would not be possible in the context of some modern language and its modern runtime which would make it a more desirable platform than the modern alternatives? As someone who works primarily in C (and is a little tickled by commentary elsewhere on this item about C programmers in the '80s and '90s that suggests everyone moved "up" from C to C++; very Microsoft!) I would say that's certainly the case, because there are already things that make C more appealing than C#, Java, etc. An extension to the type system to do optional, minimalistic reference counting rather than having to use GC in a modern language or the STL's reference-counted containers (or something home-grown) in C++ would be a huge step forward for example. The locking annotations available with Clang and GCC have removed much of the value-add for using a language which does more hand-holding around synchronization.

If it isn't that age precludes the possibility of progress, then what's the problem with age? Code rot is an illusion.

99.999% confidence.

Note the use of the word "accessible" in the original post. This is not a synonym for "pretty" or some way of demanding a particular aesthetic style for its own sake. The reality is that some degree visual impairment is not at all uncommon and that difficulty with contrast can result from any number of conditions.

I'm not sure about the original poster's statement that that site isn't accessible. I haven't tried applying a stylesheet from my browser to it, and I don't use anything to enhance contrast of text in web pages, as my vision is not impaired in that way. There's an argument to be made, though, that modern websites use coloring, layers, and a bunch of other things to achieve layouts, looks and feels to the extent that if you want to see content as it is presented, or to even find it readable or usable at all, you'll have a hard time with applying styles using your browser.

Believing that just because the web can be used differently to black-type-on-white-paper in a wide variety of ways means that every way of using it differently is virtuous is pretty mid-2000s web 2.0 logic. Contrast is useful, and its proven track record for rendering text is no mark of antediluvian shame, of irrelevance or datedness.

The FreeBSD Project has elections, and is in short order going to announce a new Core Team.

Only function pointer types. An indirect function call on some architecture, for example, could require that when one makes an indirect call one sets up several registers in addition to jumping to a particular location in memory, and none of the registers that need to be set up can be derived from the jump target. So in practice your function pointers would need to actually be structures containing those register values and the jump target. Or you might need to pass around a tuple of target and calling convention, although the C standard limits the ways you could implement that (namely by requiring that function pointers cast to and from other function pointer types will compare as equal, and will still work when they are cast to the correct type.)

For the set of features you have, with most calling conventions on most platforms you don't need to synthesize all that. You could simply have your apply function be written in assembly and handle setting up the parameters fetching them from memory.

That also isn't higher-order programming as such. Can you create new functions from doing that? There are ways to compose functions in C by hand, but the distinction is that it cannot be done elegantly. (One could always just do higher-order programming in C by constructing an abstract syntax tree, after all.)

A good first effort in that you did correctly handle calling functions without requiring them to fetch their arguments in an unusual way, which is what most people would try at first. With a varargs apply function, you can handle the case of passing values larger than a register and passing pointers without having to cast them to a list, too. Consider the case of an apply function which takes an unsigned integer as the size of the following argument. If it's zero, then the argument list is finished. Otherwise, it then fetches an argument of that size from the va_list and goes on to the next one. So then your apply function is slightly uglier (int j = 42; apply(printf, sizeof (const char ), "Hello, %s! %u\n", sizeof (const char ), "world"), sizeof j, j, 0) but perhaps more flexible, and at least avoids relying on a few nasty implicit casts.

Also, function pointers should not necessarily be cast implicitly to void *, but on only a few architectures are function pointers so strange that you'll have any trouble with your approach.

As it is, you could even avoid writing or generating any assembly by just having the apply routine be a static inline function that does a switch on the argument count and then casts the function pointer to a function pointer that takes the right number of arguments. The compiler could do constant propagation for the number of arguments and you'd have little overhead in your function calls. You couldn't handle arbitrarily-large argument lists, but it would work pretty well.

Keep at it!

How do you feel about the reported performance of "SELECT * FROM table ORDER BY id DESC LIMIT 5;"? Is this something that needs to be improved there, or are you happy with that being one of the built-in anchors?

Additionally, I'm not sure that the implementation of the hard reliable case sounds very mature or even well thought-out. Having a syncer running at 20hz and waiting for it even in the synchronous path seems a bad idea. That's kind of like adding an anchor to your anchor so your speedboat can crawl while it crawls. Or was that a misrepresentation?

And who cares if the tone is serious? The criticisms seem to be valid, and ones that anyone releasing software making bold claims should expect. Statements about performance need to be qualified. Out-of-the-box behavior is not a reasonable point of comparison if (1) that's not what people do in the real world (2) the tests you use are ones that one piece of software is tuned for and the other is tuned against. Some kind of sorted index by field is necessary for some very common and desirable queries. Some of the performance gains come at an unacknowledged cost. The durability just isn't there (and for trivial reasons that could be fixed by making a few more parameters tunable, it sounds like), but is implicitly lauded by claiming to be ACID.

I don't know if you need to go looking for praise in that article. It really seems like there are some criticisms it would be beneficial to take seriously, even if you object to the author's tone or lack of praise. Even-handedness is not a marker of honesty, and honest criticism is worth the headaches it causes and the growth it spurs if you're willing to take it seriously.

This seems like a silly point to pick on. Why is the MBP so thin? Because of design considerations and the desires of the target market. The design considerations are a serious component of the Apple brand, perhaps the single most distinguishing component. To compromise on the design to work-around the thinness which is in service to the design would just be pointless.

It may not be accurate and complete and without flaw, but it is a reasonable reduction of the reality of Apple hardware to an understandable and useful form. The difference in thickness is profound, and would have been compromised itself, or have forced a compromise elsewhere in the design of the base hardware platform, without the removal of the Ethernet port due to physical space constraints that arose from the level of space reduction that was possible with this revision of hardware.

I think that's a pretty interesting point. The Thunderbolt adapter is a design compromise and a crappy one, but it is a general-purpose one (i.e. there is a consistent peripheral platform) and one that will not impact the vast majority of users. Copper Ethernet is not at the top of Apple laptop users' desire, as one might note conversely design is. There's a sort of elegance in systematizing the edge cases and making the base case streamlined, minimal, satisfactory, beautiful and shockingly-thin.

It's a common financial strategy among the fabulously-wealthy. Selling shares would incur all kinds of taxes, but he can get a line of credit with a reasonable interest rate quite easily, pay no income taxes, and actually deduct the interest he pays from his taxes. So he carries a lot of debt but it's all backed by assets and paying the interest is tolerable.

Yes, if that's what he's doing, then in the event that his assets utterly evaporate he'll be in a spot of bother. But it's a pretty well-trod path, and probably some non-trivial portion of his assets are quite stable and reliable and not terribly volatile. I won't pretend to know the precise details of his situation, but living off a line of credit isn't at all uncommon and perhaps isn't even unreasonable (from the perspective of financial self-interest alone) for a person in his position.

The proliferation of new TLDs is already, quickly reducing some interesting shibboleths of the web. In a few years, young audiences won't be expected to realize how awkward and silly mid-'90s through '00s movie and TV show dialogue seemed when the writers threw in silly TLDs to round out their jargon. That some domain name ends in .ponycorn won't seem preposterous and silly. Probably an opportunity for someone to pick up some of the more memorable fake TLDs from recent history.

I do also wonder how it impacts organizations that have used internal TLDs to manage their intranets, e.g. the FBI's .fbi. There have to be collisions at some point, right? And as the amount of fanfare with each new TLD falls, it seems likely that some of those things could get missed, and lead to some interesting vulnerabilities.

At one point it seemed to me that the prices were sorted by the listed retail price for that particular item, and not the lowest offered price for it, or something along those lines. It's been years since I formed that wild guess, though. But it has seemed to roughly hold up when I'm (foolishly) trying to price-shop on Amazon.

The article already did. I think it's useful to support the guy, as someone who agrees with him, by cheering this as the actions of a real person that should be a source of pride, and not pretending that this is some embarrassment that should be hidden. We shape the culture, expectations and the power individuals feel to speak and to challenge authority with how we react to stories like this. I deliberately applaud @CrimsonJohn for his actions. I don't think they were wrong or shameful, or should be seen as such, and I won't pretend that they were.

His father was willing to go on the record questioning his son's sanity and trivializing the stresses of his son's life. The tech community can do better for one of our own than that.

Looks like Seagate: http://www.linkedin.com/profile/view?id=9922065 .

That much was obvious. When you build your examples around a sexist experience of sexist media, your examples will themselves end up sexist. I mean, why isn't Zoe buying, too? What is it that Inara's selling? I think we know, and from the heternormative misogyny rises the situation in which a cheeky description of market making has exclusively men buying and exclusively women selling.

Men buy, women sell, and also if women are sad you can feed them strawberries and get off on it. Got it. Now I understand HFT perfectly.

The blog, which others have mentioned and which is prominently-linked on the Sourceforge site (http://punix-os.blogspot.com/), would suggest that there is new news, and it's fairly significant. It has actually been run on real hardware rather than in-simulator, it would seem.

I find it not a little jarring that the kernel has been pasted together from code from other systems, not just inspired by code from other systems, in places. Is there a clear license statement I've missed? I'm assuming it's GPLv2, since it includes code directly from Linux, but it's hard to say even for those files since the license statements have been stripped.

Still, at least as neat as all of the excitement about the shocking new news that is a game including an emulator for a trivial, fanciful, microprocessor, and other things that Hacker News goes nuts over at great length and in a sustained way. If this is too old news for you, perhaps you'd like to read another iteration of how to hire software engineers (answer: don't), whether culture fit is racist (answer: probably), or how best to cloud your cloud cloud cloud Ruby cloud cloud bro cloud.

Right, and there are other RNG and PRNG sources and interfaces for precisely that reaon. The question was why random(3) isn't arc4random(3).

Yes, because of the need for pseudorandom sequences. In FreeBSD this comes up every so often, but the reality is that there's a lot of AI and simulation/modeling code that uses the libc random functions (either rand(3) or random(3)) and expects reproducible behavior with the same seed both throughout the life of a program and across multiple executions.