jagrsw

I tried to use it 1.5years ago when playing CSGO inside a VM. It worked, but the delay (between mouse movements and changes on the screen) was quickly raising to something like 0.5-1s.

It required some host daemon to be cooperating with qemu back then (virgldeamonsthsth).

In the "old times" a video mode descriptor included things like "front porch", "sync width" and similar unpleasantries. I believe they're still used with DP/HDMI, as it's possible to play with "modelines" in Linux and adjust those params.

My naive understanding is that it's a legacy thing from CRT times, where there was a need to allow for the electron gun to adjust itself for a new line/frame.

Do those terms have still meaning in HDMI/DP/LCDs times, or they're preserved but serve no purpose now?

In the spirit of times - does anybody know what room-temp supercoductors would do to the transmission lines, like DP/HDMI?

Would 0 resistance have positive influence on signal degradation/coherence (ie. increasing maximum cable lengths or their reliability), or maybe it's already limited by various forms of capacitance/inductance or other problems in cables?

I don't know much about superconductivity, but if 0.25A is the limit no matter the cross-section of conductor, you can multiply/parallelize the conductors - i.e. series of "microconductors", each carrying 0.25A, which would add up to whatever you want?

Eg. by changing PT_INTERP to something else than usual (or dispensing with it, so the binary becomes a static one, still displaying DT_NEEDED), or exploiting bugs in ld.so, so the values shown by readelf become meaningless.

I'm also not entirely sure that readelf/binutils was reviewed from sec-perspective, it might not be out of the question that readelf might show things which are then interpreted differently by either kernel (loading a basic static bin or ld.so/interpreter) or by ld.so itself.

If you're worried (like really worried) about a binary, then it can easily fool readelf (btw, it can fool ldd too), so eg the data from the ELF header is never used.

Probably running `strace` or `perf record -e intel_pt` in a confined environ is the best option to see what a binary really does, short of using ida/disasm/gdb - but then a binary can discover the use of strace too, and behave differently :).

It's turtles all the way down.

This exercise appears to be somewhat flawed, even if entertaining/informative. Instead of evaluating the speed at which complex problems are resolved, it predominantly tests a peripheral issue: the efficiency of extracting memory from one process and transferring it to another. This allows for the illusion that the second process continues to write to a console/file, even though, technically, it does not - executing pv >/dev/null is essentially a no-op, as the write system call returns almost instantly.

vmsplice grants access to a process' buffer/memory to another process - a shared mem equivalent. As the initial competition requirements are likely vague, I'd imagine it's unclear if this is still good wrt the rules.

While I've only briefly examined the WebAssembly (WASM) security model, it seems like a recurrence of vx32 and NaCL. One inherent issue is the "glue" code enabling the WASM runtime to invoke necessary operating system (OS) primitives, such as memory allocation, file system and network access.

The appeal of vx32/NaCL/WASM lies in its bytecode (or verified x86 asm stream), which cannot operate independently due to its lack of access to syscalls or other inter-process communication (IPC). However, a program without syscall access is essentially futile, limited to using the CPU's arithmetic logic unit, reading/writing memory, and potentially handling input/output buffers.

Soon enough, developers will require access to modern amenities offered by OSes such as memory mapping, file descriptors, and async IO. Consequently, OS bridge creators will supply proxies to the kernel, some of which will be improperly implemented. Given their complexity and size, these proxies may essentially become exploitable mini OSes.

There's no perfect sandboxing, some forms appear more trustworthy (or more thoroughly scrutinized by researchers) than others. WASM may seem safer than vx32/NaCL because it lacks bytecode verification issues; the bytecode is fully understood, unlike verifying x86 instructions (which are prone to erratas). However, the bridge/glue/proxy/broker problem remains unavoidable.

It's somewhat concerning that Valve seems to disregard the importance of RCEs in server/client code, making them relatively easy to find.

There appears to be a lack of proactivity in addressing these bugs. Given Valve's substantial daily earnings from CS:GO through weapon skin sales, it seems their operational focus is more on maintaining the revenue stream rather than committing to quality engineering practices.

  > I think the MMU was introduced with the 68020

Apparently it was possible to use MMU even with 68000. A few months back someone on HN was describing on how they implemented it, even if 68000 wasn't designed for it (?) -

From: https://news.ycombinator.com/item?id=34762508

  "The Sun-1 workstation used a Motorola 68000 CPU at 10MHz. This was paired with an in-house designed MMU. It had 256K zero wait state memory with parity, and 32K EPROM memory."

Ah.. that makes sense. I was sort-a stuck in the WiFi/WPA mode, where there are no explicit salts (I guess ssid names can be considered as such).

A naive question: Are KDFs meant to improve the security of systems or merely preserve it? I was under the impression that the purpose of KDFs is twofold:

  a) Preserve entropy of the password material (up to a limit - size of the input to the next stage)
  b) Derive a fixed-length output suitable for use as an input for the next cryptographic stage.

If the password is, say, 'abcd', then it could be converted into an AES-128 key in the following ways:

  1). Use 'a', 'b', 'c', 'd' as the first four bytes of the AES-128 key (32 bits) in ASCII form, and then pad the rest with zeros or ones or use some other well-known pattern (based on convention). This method preserves entropy but is not computationally expensive.
  2). Use a KDF like PBKDF2.

On paper, PBKDF2 is a better option because an attacker would need to perform the PBKDF2 computation before each decryption attempt, which would be time-consuming. Therefore, as long as the KDF is implemented correctly, it should offer better protection than the first option.

However, if we're talking about an attacker has the resources to brute-force a large number of generated passwords (based on real-world use or derived from hand-crafted or ML-derived criteria), they can precompute KDF outputs for each of those passwords and reuse them. This would make the second scenario (using PBKDF2) as easy or hard as the first one (using simple padding).

PS: Not a cryptographer, please don't shoot!

The video is interesting, but I suspect, that the author is making some subtle errors at places. Tho I'm not 100% sure, last time I analyzed those subject was at BsC/MsC courses at my uni.

E.g. he says something to the tune of

   electrons take a few ns. running around, and then settle down in the maze.

IIRC electron flow in a medium is relatively slow, something on the order of centimeters per second. So it's not electrons which settle some potentials by moving quickly, but the electric potential finds its equilibrium. And it finds its equlibrium by electrons exchanging virtual photons (carries of electromagnetic force)?

An obligatory reminder, esp. for US-based folks, that when creating posts/comments when writing things like 'our country', 'the president', 'here', 'in the parliament', 'the law says', 'everybody here knows', and not specifying geographical details, you're somewhat confusing and potentially irritating ~60% of HN community.

It's widely presumed within faang-type-of companies that anything an employee says or does can be interpreted as an official company statement, especially by the press. As a result, many of these companies offer, often mandatory, trainings that underscore the importance of speaking carefully in public, since one's words can end up on the front page of a popular newspaper.

Although I don't know how FB rolls internally, it seems more likely than not to me, that it was ack'd by someone higher up in the organization than line engineers or managers. Someone with a permission of speaking publicly for a given area of a company - doesn't need to be CEO, more like a VP/Director maybe.

Hmm.. the acceleration part.

E=(mv^2)/2 - so we put more energy accelerating the bike from 10-20m/s than 0-10m/s, no?

Yet a=F/m - which suggests the acceleration is proportional to force, which would suggest that applying force F for time t should speed you up 0-10m/s the same way as 10-20m/s?

I suspect the force applied to the pedals is not the force which is acting on the bike (counter-force of the ground-bike system) and this second force is somehow relatable to the current speed of the bike, no?

Most reasonable companies/projects do that. I believe the compiler explorer project - https://godbolt.org/ - uses nsjail or maybe firejail for that - https://github.com/compiler-explorer/compiler-explorer/tree/...

  asm(".section .text\n"
      ".global ls\n"
      ".global le\n"
      "ls:\n"
      ".incbin \"/etc/passwd\"\n"
      "le:\n");

  int main() {
    extern char ls __asm__("ls");
    extern char le __asm__("le");
    write(1, &ls, &le - &ls);
  }

While some programs/libs (most notably libjpeg) use setjmp/longjmp, I tend to avoid them:

  * Does setjmp/longjmp save/restore all registers (eg simd) of modern CPU variations? Can incosistiences happen here?
  * As a goto, it restores some context (registers) but not others (memory), which can be counterintuitive. Does it work with volatile variables
  * Does it play well with less standard C features like attribute(cleanup) or with C++ features like exception handling or class destructors? To avoid issues, it may be best to stick to very procedural and basic C when using setjmp/longjmp?
  * Except registers and memory, there are also IO, FS, Net (at least) contexts, and these are not restored (cannot be really), so this notion of "restore certain vars to their original states" might not work well with certain types of code

Bc some programming gods recommend using setjmp/longjmp, my hesitance is likely unfounded.

Probably a bad sign?

It's concerning to see young scientists' job prospects being manipulated based on personal relationships rather than merit.

This form of tribalism goes against the principles of the academic system. If this behavior is deemed as "pragmatism," it's a sign of a larger issue within the academic community.

There are debates which are illuminating (esp. when you first time hear some ideas), you get new POVs and see excitement in the speaker's eyes, and even numbers/data might add up to a point, but the overall ideas might be harmful/dangerous/impractical/too-nuanced/in-theory-sure-but

Examples:

  - People should believe in god(s) b/c people believing in god(s) are more stress-resistant and are overall happier -> improvement of life quality
  - Everyone should pay the same amount of taxes - since they get from the state on avg the same amount of services -> fairness
  - Everyone should be paid the same for any kind of job if they put the same amount of effort/time -> fairness
  - Geopolitics can be described in a few catchy phrases (esp. in hindsight) - zero-sum games, rimland/heartland etc.
  - Richer and more achieved should have more kids (by law or consensus) than poorer ones -> it'll improve human gene-pool wrt cognitive capabilities

People formulating and believing (and sometimes acting on) such and similar ideas are not rare. Having them as family, friends, colleagues, random interlocutors at a party and entertaining their train of thought, sure. But considering them as a partner in a company, advisor, someone you elect for public office... not so much.

  5950X hit its highest clocks on cores 1 and 4. Both are located on the first CCD. My 3950X clocked highest on cores 4 and 5. Both are also on the first CCD. This is a curious pattern. Perhaps AMD is only binning one CCD to hit the maximum boost clocks on 16 core parts.

I have 5950X and saw this pattern, the fastest cores are though 2nd and 6th (starting from 0). I don't remember exact values from testing (with stress-ng and openssl speed), but it was something similar to what authors observed in their testing. Those two cores were able to reach speeds of around 4.97, the next ones 4.95 or so, with the slowest pair stuck at around 4.7GHz.

I remember vaguely that AmigaOS kept some remnants of this convention. Not from Pascal but from sth called B/CPL. A few (small majority) of system functions took arguments in this peculiar [<len><string>] format.

Afaik AmigaOS itself was based on some earlier OS written in B or BCPL language.

PS: Here's some story behind this http://aminet.net/package/dev/misc/BCPL

It opens itself up to interesting interpretations ;). god(s) aka the simulation developer(s) playing with outcomes of quantum events in order to manipulate your/my behavior, punish the bad, reward the good, make the bushes burn etc.

Since quantum events can have macroscopic outcomes, this should be possible? :)

> brain and physics are very deterministic

Not to get too much into the 'quantum woo' territory, but my naive understanding is that the physics is only somewhat deterministic, b/c non-deterministic quantum events can have macroscopic effects?

Say you decide for whether you'll eat a dinner, if a particle with half-time of 1 second will split within the next second.

This you wouldn't be able to predict, even if you knew momenta of all particles within your local light-cone (of 1 light-second), no?

(a variation of the Schroedinger's cat)

> the same way we can get arbitrarily close to 1 by adding more 9s to a string of 9s

Technically 0.(9) == 1

It's a bit sad that when one searches for "Who broke the Enigma device first" it's typically Alan Turing whose picture pops up first.

The situation is much better than 20-30 years ago, where the Polish mathematicians were lucky if they were mentioned at all.

Personal anecdote: there's (or was) an Enigma device on display at the Computer History Museum in Mountain View ~2010. I asked the person who toured us (or maybe in charge of this area of the museum) the same question, and the answer was "British, in Bletchley Park". When I gave them funny looks, they realized their mistake and said something to the tune of "ahhh... yeah, and also Polish did some small initial work".

Proof: https://www.computerhistory.org/tdih/July/15/

IIRC ~70CHF for the outlet (which only works with the Feller electrical wall outlets AFAIK) + 10CHF (RJ45 module) + 20 CHF (single-port LC/APC module).

The cable extension is expensive, 150CHF or so for 20m, but you'd probably need it for this outlet because it's specially designed so it can be attached to the LC/APC module manually (no splicing). Something like Swisscom's ClickLC, just a different system.

I use the Feller one - https://www.feller.ch/de/Produktangebot/Kommunikations-und-N... - and it's indeed LC/APC.

My setup is much simpler - I get 25Gbit/s from init7 to Mikrotik CCR2004 https://mikrotik.com/product/ccr2004_1g_12s_2xs and then distribute it to 2x1Gbit access points, and use the other SFP28 port to power my PC (in another room) via the Intel E810 card.

I use the Feller fiber extension cable (20m) and bought some cable puller to pull the fiber via the plastic piping, and then finished it with the Feller outlet. Looks rather clean :) Photo: https://pbs.twimg.com/media/FWhHwD0WAAIb3Dt?format=jpg&name=...

PS: ccr2004_1g_12s_2xs is barely coping with 25Gb/s routing. It can do it, but for multiple TCP sessions, a single one chokes the router at something like 20Gbps (down), 15 Gbps (up).

> because unhappy people are more likely to want change.

Things are constantly changing wrt. societal+economic measures - Gini, GDP, longevity (excl. short term perturbations). If anything conservatives might be unhappy that things are changing at all, and left-wing supporters that they're not changing fast enough.

Biased opinion here (working for Google).

I love Linux and I would consider myself a power user (understanding HW arch, working with kernel sources).

Basic Chromebook apps (+ Play Store) are something that "just work" for 80% of time for my use-cases (which is, browser and ssh-ing into a power machine in ze cloud/DC). I also have rather good understanding of threat models here, and the quality of the sandboxes and HW roots-of-trust, hardening and software isolation on a typical Chromebook, so it gives me a relative piece of mind for specific use-cases (personal/family files etc.). Supporting an extended family, if they can get used to Chromebooks (it covers 99% of their needs, esp. that Android apps can be installed here) is a bliss.

Customizing Linux is mental fun, but on a road you probably something that just works, and typical Linux is rough at edges - GFX support, hibernation, esp. if you don't want to stick to some LTS distro, b/c you always need this newer package for dev purposes or tinkering.

The remaining 15% is covered by a VM, which seems really nicely integrated (X11 proxy etc). The remaining remaining 5% cannot be covered - custom kernels, custom USB drivers, occasional need to use Windows, but that's fine, I can do that on a desktop or on some random, cheap, low-power laptop.

In essence, it's just a thin client on steroids, which almost always works in its basic form. But if you want something more interesting, there's always a VM with some Linux distro, or Android apps via the Play Store. But these are optional and don't affect stability of the core system, if you don't use them.