lambda

I'm not sure exactly what would have been the right markets, but I think that something where legacy compatibility is less important and being open to experimentation and new software designs is more important. So, things like consoles (going up against things like the Cell processor), HPC, or maybe even the embedded space (tablets, etc), rather than trying to use it for the enterprise market as Intel and HP did, where running legacy pre-compiled applications is a really important use case.

Oh, yeah, I'm aware of many of the reasons that IA64 failed.

Intel could have solved this problem by contributing to GCC and LLVM instead of keeping their optimizations proprietary. Then they would also be more easily auditable as well.

You used to be able to buy Lemote Yeeloong notebooks, which in addition to having Loongsong processors had completely free software BIOS, making them one of the only RMS approved pieces of hardware. But I'm not seeing those readily available any longer.

Why give up on performance?

IA-64 (https://en.wikipedia.org/wiki/IA-64#Architecture) already exists, with its explicitly parallel instruction set, which leaves branch prediction and speculative execution up to the software. So you can still get many of the performance benefits, but it's under control of the software, giving a lot more flexibility for being able to mitigate or eliminate these kinds of issues.

I think that it was probably introduced ahead of its time, and targeted at the wrong markets, but it's kind of sad that with the Spectre vulnerabilities, we don't have any way of comprehensively addressing it in software without jumping through a lot of hoops and applying microcode updates.

Avid Media Composer, one of the most popular non-linear video editors in the industry, does a stat of every piece of media referenced in every project you have open when you change focus from another application back to Avid Media Composer.

Since I work on network attached storage for video editing, I'm acutely aware of how much slowing down a few simple syscalls by just a little bit can be for certain very commonly used applications on macOS.

The front page is not very obvious, no.

My mind did go to debugging tracing, but the exact form of debugging tracing is not very obvious from the front page.

> Why not use a statically typed language for such a large code-base? Is this done by purpose, or did they end up with a million lines of Python code and are looking for ways to make the maintenance easier?

Being in a similar (though much smaller scale) situation ourselves, I suspect your latter suggestion is the answer; they wound up with a large amount of Python code due to expediency (Python is good at quickly getting things done), and are now finding the code base quite hard to maintain.

Something to remember is that as of 10 years ago, statically typed languages consisted of C (for some definition of "statically typed"), C++ (complicated and cumbersome, and didn't yet have widespread availability of "modern" C++ features), Java (cumbersome, heavyweight, lots of missing opportunities for abstraction back then), C# (heavily tied into the Microsoft ecosystem, not yet open source), and a bunch of weird academic languages that required tutorials about burritos to learn (ML, Haskell, etc).

While statically typed languages like C, C++, and Java were the mainstream languages of the 90s, C was too limited for a lot of people, C++ and Java too cumbersome to use, and so lightweight dynamically typed languages like Perl, Python, PHP, Ruby, and JavaScript picked up a lot of steam due to how much easier to pick up and more productive many programmers found themselves in those languages. But now we have large, fairly un-maintainable code bases in these languages, and people are realizing the value of static typing, in part due to the maintenance hassle and in part due to newer, more expressive and accessible statically typed languages being available (Elm, Rust, TypeScript, Scala, Go, Kotlin, as well as improvements to C++, Java, and C#).

But that leaves all of these old codebases, that are hard to maintain. Rather than doing a complete rewrite, adding static typing capabilities that can be applied to existing codebases is a way to make them more maintainable without spending all of the time of a complete rewrite and having everyone have to spend all of the time learning the new language while still maintaining the old codebase.

I've been considering doing a static/semi-static blog system which just notifies the user of discussions on referring sites, and makes it easy to link to and excerpt interesting discussion. Possibly even gives an easy way to submit links to start discussion on preferred sites.

That way, everything displayed on your blog is explicitly added there by the author, but once an interesting discussion has started you can easily direct users to it and they can participate under moderation rules of whatever forum that is.

I'd consider myself an expert on Git, and I use a GUI of sorts for the vast majority of my Git work: Magit in Emacs.

It has many of the advantages that you describe; makes it easier to get an overview of what's going on, makes it easier to stage individual files, folder, lines of code, hunks, etc.

There are a couple of cases in which I need to fall back to the Git command line, but it's not very often, and I do find it substantially improves my life.

I use Droid48: https://play.google.com/store/apps/details?id=org.ab.x48&hl=... (https://github.com/shagr4th/droid48)

And an HP48 emulator is still what I use on my phone as a calculator.

For the reason you mention, I need to get into the habit of using Calc for my quick calculations; right now, I usually use Google (ick, infix notation) or dc.

Why would you think it was a single person?

Many of the large transactions are likely payment processors moving bitcoins into and out of exchanges, not any individual. Or mining rig operators cashing out to finance their power bills (and I'm talking the big mining operations, not someone's one or two miners in their apartment).

If you read the article, you'll see:

> Lincoln Stoll’s k8s-vpcnet, and more recently, Amazon’s amazon-vpc-cni-k8s CNI stacks use Elastic Network Interfaces (ENIs) and secondary private IPs to achieve an overlay-free AWS VPC-native solutions for Kubernetes networking. While both of these solutions achieve the same base goal of drastically simplifying the network complexity of deploying Kubernetes at scale on AWS, they do not focus on minimizing network latency and kernel overhead as part of implementing a compliant networking stack.

Casino dice are actually cubes, at least as close as manufacturing tolerances of 0.0001 inch can make them. For example:

https://www.casinosupply.com/collections/casino-dice/product...

This is to help make it easier to spot alterations or flaws which could affect their randomness; shaved corners become very easy to spot, when packing them together it's easy to spot ones with height differences, etc.

The first amendment applies to the actions of govnerment officials, not private parties.

In the meat-space analogy, the mall is still able to kick out people for violating its rules on conduct, but government officials are not allowed to, nor are they allowed to ask the mall to kick people out on their behalf.

> Trump can just drop twitter

Can he, really? It is his favorite medium, the one that allows him direct access to a large base of devoted fans, and allows him to state his mind publicly in a way that is not filtered by aids, media organizations, and the like.

From the rendered manual that is linked from TFA

https://dspinellis.github.io/unix-v4man/v4man.pdf

> This manual was set by a Graphic Systems phototypesetter driven by the troff formatting program operating under the UNIX system. The text of the manual was prepared using the ed text editor.

One reason I could see is if upgrading in place is substantially faster or cheaper than migrating data to new ones.

For instance, if the nodes are storage nodes in a redundant storage system, taking each one offline briefly for a reboot, and letting the others handle the slightly higher load, is a lot quicker than spinning up a new node and replicating all of the data over there so you can de-provision the old one.

Also, even if they don't have a lot of data, the time and resulting expense of spinning up and provisioning a new node while the old one is still online could add up to higher costs than just performing a reboot during a point of lower load.

> For pretty much complete nonsense NIH and standards-lawyering reasons.

You consider the fact that there is no spec other than "how the current implementation works", so no way to know if the code than works on version n will continue to work on version n+1, and no way to produce an alternate implementation, is a "complete nonsense reason"?

I also believe that it wasn't just Mozilla, but also Microsoft that scuttled this. Mozilla was the louder voice, but Microsoft never supported it either.

> A signed app is only more secure if they load absolutely no code remotely

Which they don't. That's why it's not a web app.

> That said, I feel like I've seen the "Google releases [x]" headline on Hacker News more of late, and I am not sure if that's because submitters are excited and editorializing, or if there's genuine confusion. I'd love to hear any thoughts people have on that.

Yes, I've been seeing this a lot lately too, and am frustrated by it because it seems to imply a much bigger commitment on Google's part than "this is an employee's personal side project". Hence why I posted the note.

Thank you for the clarification on the exact policy; since I'd been seeing a lot of these side projects posted under the Google account on Github, I figured it was something like that, but it's nice to see it spelled out.

> (This is not an official Google product)

It appears that Google's policy is that all open source personal projects be hosted under its GitHub account. Thus, I think "Google open sources" is a bit misleading; that implies that it's an official project being used by Google, whereas this just looks like a personal project being hosted by Google due to their requirements.

So what's the current status of the upstreaming work? It sounds like there's a good start discussed in the paper, in removing a lot of conditional and duplicated code and using some more cleanly separated layers, but that was two years ago, what's happened since?

I don't know about Windows, but on Linux, I would love to have a replacement for the entirety of NSS (and PAM, and other similar parts of the system) that ran in separate daemons rather than by loading shared objects into my process which could arbitrarily corrupt my process if they were buggy (which I have encountered before before).

To achieve that compatibly with existing systems, it would probably need to be able to act as an NSS module itself in order to be compatible with existing clients, and also be able to load NSS modules (hopefully in sandboxed, lower privileged processes) so it could support existing setups transparently, though it would be great to also have a better asynchronous interface so that you don't have to spawn thread or process pools for things like hostname resolution or fetching groups from LDAP.

There is the UDP source port, which is where the reply will be sent, and a 16 bit ID number associated with each request. Randomizing both of these gives you 32 bits of entropy, which would makes spoofing attacks a lot harder. There were a lot of systems vulnerable to such attacks before source port randomization and ID randomization became common to mitigate such attacks.

https://en.wikipedia.org/wiki/DNS_spoofing

Of course, for this attack, you may only need to get the source port to match, since if it's the DNS resolver that has the bug, it may parse the whole response before noticing that the ID doesn't match. And some NATs may break source port randomizaiton, since they allocate their own source ports to keep a table of their source port to the internal IP and source port; if they do so in a more predictable manner, it may be relatively easy to spam them with packets, or you could just spam the whole 65536 bit range with bad packets.

The code is pretty short and easy to read:

It parses the card names and IDs from a CSV file here:

https://github.com/minimaxir/magic-the-gifening/blob/master/...

And calls create_mtg_gif, which calls get_giphy_gif, which requests GIFs from the giphy API by searching for the card name, and then finds one that has an appropriate aspect ratio.

https://github.com/minimaxir/magic-the-gifening/blob/master/...

While I mostly use Emacs and have only actually written a little bit of Rust, from what I've gathered the two best IDE experiences are either VSCode with RLS (Rust language server, which uses an adaptation of the compiler for reporting syntax errors and various other information like jump to definition, coupled with a simpler but faster engine for things like autocompletion so that you can start doing that before the server finishes a full compile) and the Rust IntelliJ Plugin which uses IntelliJ's native tooling and adapts it to understand Rust, which has the advantage of all being originally written for fast and robust autocompletion, highlighting, and the like, rather than adapting something written as a compiler to provide that information, but the disadvantage that you need to implement a lot of Rust's syntax and type inference so there are some more complicated cases that it can't necessarily handle yet.

If you're interested in trying out a Rust IDE, those are the two I'd try and see how you find them.

Looking at their commit history, it's not a fork in the sense of "we're actively developing our own new features and diverging from upstream", it's a fork in the sense of "we've taken a stable release from upstream, applied some of our own patches, some backported patches, and some patches from other forks."

It's a fork as much as the stable packages that RedHat or Debian ships are "forks" since they have a few patches applied to customize for their environment and fix a few issues that hadn't made it upstream by the time they picked a stable release to base on.

MariaDB is an active, independently developed project. They are probably funding MariaDB because working with upstream developers of an actively developed fork can be more efficient than striking out on their own with another actual fork. I wouldn't be surprised if they eventually start using MariaDB, and either rebase their AliSQL patches on top of it or drop AliSQL altogether (much of it just looks like backports of bugs or features).

At rendering the content available at the time.

> However having something available as part of DB or Hadoop ecosystem enables reproducible execution while taking care of compliance (e.g. privacy), security, access control etc.

You are conflating a couple of things here.

Of course for real analyses, you want to run them on standardized environments with appropriate access controls.

But nothing says that "standardized environment" has to use a distributed database that, from all accounts, seems to harm more than help.

You could just have a RDBMS or even filesystem, which is appropriately backed up or replicated, on a single beefy VM or physical machine.

> The real opportunity lies in ability to add arbitrary compute/memory capacity to DB query execution flows.

Only if the tools used to provide that ability actually allow you to take advantage of it. If scaling up to 160 nodes doesn't allow you to be any faster than 1 single laptop, you probably could have spent a lot less money on just adding more RAM to a single beefy server than a 160 node cluster.

You run into different, but similar, issues cloning Linux on macOS as well, since HFS+ is case-insensitive by default (and looks like the same is true of APFS), but the Linux source has filenames that differ only in case (don't ask me why).