HackerTrans
TopNewTrendsCommentsPastAskShowJobs

xfs

no profile record

comments

xfs
·3 ปีที่แล้ว·discuss
https://youtu.be/_qaKkHuHYE0 (CppCon) A senior software engineer at Google tried to optimize tcmalloc by replacing a mutex with lockless MPMC queue. After many bugs and tears, the result is not statistically significant in production systems.
xfs
·4 ปีที่แล้ว·discuss
KCP uses a brute force congestion control algorithm that is unfair and inefficient. It is also poorly specified, which is probably why it is less commonly used outside circumvention circles.
xfs
·4 ปีที่แล้ว·discuss
From Steve Yegge:

What really happened is that China hacked Google, and it pissed Google off when they finally discovered it, many months later. This wasn’t some small intrusion or data breach. It was a systemic, coordinated, widespread, very deep hack, which among other things, gave China all of Google’s source code. It was very similar in scope and ambition to the Solar Winds hack recently out of Russia. It forced Google to completely rethink their security, which at the time was an Igloo model (hard on the outside, soft on the inside, a Gary Larson reference I think), and they had to migrate to where internal access was also limited, which took years.

I’ll share with you, confidentially wink wink, that most companies way overvalue their source code. It’s actually their engineers who are their biggest asset, because the engineers can reproduce the source code if it’s lost (quite quickly at that), whereas the source code can’t do fuck-all on its own. Moreover, most source code bases are so ugly that you couldn’t give them away. But Google had what they now call “HIP” (High-value Intellectual Property) scattered through their source code, which are the tuning parameters and constants for various algorithms and AI models which are the true Secret Sauce to Google’s Search and Ads dominance.
xfs
·4 ปีที่แล้ว·discuss
Sure, it's common to have it working for a long time, because breaking changes and interactions between different systems occur very infrequently at the level of bootloader and firmware, but when it happens it can easily get into very difficult support situation. Logistically speaking, firmware is not a nice place to play around. It's not well coded, not well tested, and rarely "used" by an end user.

For one I wouldn't put great confidence in a script to manipulate UEFI boot entries, because it is not idempotent and there are precedents to brick the UEFI with unexpected sequence of interaction. Also Windows' reboot options and its annual upgrade tend to mess with the boot variables. I had to help repair colleagues' laptops that had Grub's boot entries erased by Windows upgrades.
xfs
·4 ปีที่แล้ว·discuss
I have used EFISTUB for 10 years but I wouldn't recommend it for the next install. The bootloader is the one arcane place that you don't want to be clever with and get reminded of its presence daily, because once it fails for some reason, it wastes much more time to find and read docs and diagnose than the time saved in boot speedup, because the knowledge to debug it is not something you would remember everyday. And this setup is even rarer than Grub, so any failure cases will not have help from cached knowledge and thus require much more research from first principle. Some backup options here would help in case, even if they impose some tax in boot speed. (If Grub takes a tax of 3 seconds per boot, and if a failure in EFISTUB takes 1 hour to resolve, it takes 1200 boots for EFISTUB to be worth the risk, which is 3 years if it's a laptop booting once per day, and much longer for a desktop.)

Once my desktop using the EFISTUB setup had a kernel that failed to boot, stuck at some filesystem error. Then I had to come up with a rescue plan at the spot, because there was no other way to boot into the desktop and there was no tutorial to help with this at the time.

The issues of EFISTUB:

- It doesn't interact with kernel updates nicely. I used a script in /etc/kernel/postinst.d to copy /vmlinuz to \EFI\debian\vmlinuz.efi. There is no rollback, and no multiple kernels.

- It doesn't work well with kernel parameters. The parameters are encoded in UEFI NVRAM. You have to create separate entries for different kernel parameters, or manipulate the NVRAM back and forth with efibootmgr, which is another gun that easily shoots the foot (you can easily mess up the bootorder variable).

- It doesn't play nicely with Windows and Secure Boot.
xfs
·4 ปีที่แล้ว·discuss
OK, maybe "Turing test" was a bad hint because too often its extension turns into a philosophical rabbit hole of defining intelligence.

I want to get back to your initial statement about uncovering and structures, which I think is still grounded in the empirical realm. I think a less ambitious new test could be about the "uncovering" between analog data and the structures. To be real uncovering, the structures must be symbolic, not just transformed analog representation, and the symbolic structures must be useful, e.g. provide radical reduction of computational complexity compared to equivalent computation with analog data.

The point is to test if the machine can make the right abstraction (real uncovering) and also connect the abstraction with the data, not just games with words.
xfs
·4 ปีที่แล้ว·discuss
The Heideggerian point is a start, but I don't think it's enough to just point out a failure like this. This allegation is something like "The answer is already encoded in the question" like of trick, similar to one played in Foucault's episteme, where science itself is always-already a social construction without which it is impossible to happen.

The trick is challenging on first sight but it won't go very far, because it just tells us what ML lacks but doesn't tell us what ML can have and how to go there. We need a new kind of Turing test that actually reflects the power of human intellect.
xfs
·4 ปีที่แล้ว·discuss
Human can't visualize a tesseract, but human can conceptualize the Idea of a tesseract in the symbolic space, by math, physics, or in other words, by Reason.

The Symbolic is a radically simplification of all the complexities impossible to be fully sensible. Even though the simplification is always particular, contingent, and full of ambiguity (human languages) and often inaccuracy (Newton's laws vs relativity), without the simplification, without Reason, ML systems are probably like animals, eventually succumbing to the full force of the complexity of reality.
xfs
·4 ปีที่แล้ว·discuss
Plenty of RL systems learn to play video games just fine without fine-tuned rewards, but I see this line of thought isn't actually what you're getting at.

I would assume serious ML people would not be overly ambitious and overstep their claims beyond empirical realms. You were saying ML "uncovers latent representational structure not present in the data", but I would guess the claim, if that is what you're going against, is merely that the latent structures exist, and no Truth is really "uncovered" by ML per se, in the Heideggerian sense.

I agree ML hasn't really produced an Understanding of the world. The carving along the joints is in other words a symbolic abstraction of the world that is a radical simplification, for which only Reason is capable of, and ML hasn't shown to be capable of Reason. As an aside, I also would not assume the ambiguity you refer to can be fully eliminated even by human intelligence, just see how languages are fully of ambiguity, or even quantum mechanics.

But again, when philosophical critiques are launched against ML, the usual story is ML advocates would retreat to the success of ML in the empirical realms. I'm reminded of the Norvig vs Chomsky debate by this.
xfs
·6 ปีที่แล้ว·discuss
First I thought reading /etc/machine-id would be expected if Chrome uses D-bus or pulseaudio libraries which depend on D-bus, and /etc/machine-id is part of D-bus. But no, they really use it for tracking purposes.

And in a sick twist they have this comment for it:

  std::string BrowserDMTokenStorageLinux::InitClientId() {
    // The client ID is derived from /etc/machine-id
    // (https://www.freedesktop.org/software/systemd/man/machine-id.html). As per
    // guidelines, this ID must not be transmitted outside of the machine, which
    // is why we hash it first and then encode it in base64 before transmitting
    // it.
xfs
·7 ปีที่แล้ว·discuss
I used to not use ad blockers as I'm not bothered by ads. But it's getting increasingly difficult not to because the ads are making thousands of requests downloading hundreds of mbs of who knows what quite often simply crashing the tabs. It has got to the point that ads and analytics are being added so mindlessly (I saw it first hand as random CPU hogging battery killing trackers were pushed onto my single-page web app by product managers) that browsing without an ad blocker isn't viable anymore performance-wise.
xfs
·7 ปีที่แล้ว·discuss
This interface raw_data_->ToArrayBuffer() sometimes returns a copy of its internal buffer and sometimes returns a smart pointer to its internal buffer. See https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5...

But DOMArrayBuffer::Create() here takes ownership of the memory from ToArrayBuffer(), so in the latter case of a smart pointer, the internal buffer of raw_data_ is immediately invalidated and its value becomes undefined after creating the DOMArrayBuffer. This is fine if file loading is finished at this point because raw_data_ is reset to nullptr, but if the load is partial, then the undefined value in raw_data_ will be reused to create another DOMArrayBuffer which is then accessible in javascript. Hence the use after free.

I'll attribute the root cause of this bug to unclear memory ownership passing in interface design.
xfs
·9 ปีที่แล้ว·discuss
If IPFS is not entirely stateless the protocol to set up the state will always have identifiable information, like how TLS is easily blocked in the same way. Also, a protocol-agnostic approach is traffic analysis with machine learning (this is being used to identify custom-protocol VPNs).