happy-dude
Joined 14 years ago
Karma
285
Submissions
44
Member since
Aug 18
Recent submissions
Comment · 11 months ago
Sure, and the VR market hasn't ossified and settled yet so it's still anyone's game.
Comment · 11 months ago
Absolutely. This is a long term strategy stemming from the moment Microsoft spawned their app store.
A lot of people are missing the fact that the Steam Frame is Valve's attempt at staking a position in the wide-open and malleable VR space.
With Google, they identified that Microsoft developing their own search engine as an existential threat. Additionally, Internet Explorer being the only bottleneck for the web as a platform was a problem. And thus they broke it wide open, developing web technologies, investing in Firefox initially, releasing Chrome, and ultimately delivering Android.
In mobile, Microsoft came too late to respond to Apple and Google.
Meta and Apple have identified that VR is one of the next gold-mines in terms of a similar app-store and experience rich ecosystem potential comparable to PCs, web, and mobile, and have poured billions into development of hardware and software. It's documented that Meta attempted to create a proprietary OS for their VR headsets (and has debatable success).
Valve, while having fewer resources than any of the behemoths above, decided to hedge their bets with Linux and entering the market first through their well established brand built with video games. It would not surprise me if the Steam Frame begins their entry into other entertainment experiences and app opportunities. Microsoft has reasonable success weaving their ecosystem together (PC + Xbox), but they're foolish to think that their dominance would continue into VR because they have the PC space... They made that mistake with Windows Phone.
Comment · 1 year ago
The blog post mentions[1] that advanced views are in development. This initial release and announcement focuses on the underlying foundation they're building upon.
> New views: While we support all the fundamental views, we're planning on adding more advanced views such as a watch list, memory view, disassembly view, and a stack trace view
Comment · 2 years ago
nvim-orgmode [1] is also available. Knowledge from emacs orgmode should carry over without much issue. I didn't feel like there was a need to reinvent the wheel like neorg does when there were powerful notetaking solutions available; does anyone have a comparison breakdown of features and capabilities?
Comment · 2 years ago
You would love this article: https://www.nplusonemag.com/issue-19/essays/chat-wars/
Comment · 3 years ago
Note that ublock.org is not Raymond Hill's ublock origin [1]. (Edit: then parent comment was edited the point to gorhill's mv3 chrome extension.)
Here is ublock origin's experimental mv3 version with detailed notes on limitations: [2] [3]
[3] https://github.com/gorhill/uBlock/commit/a559f5f2715c58fea4d...
Comment · 3 years ago
While the TrailOfBits post is informative, they extrapolate the wrong premise from Brendan Gregg's original post[1]. Brendan's statement was originally about the particular set of eBPF tools created for observability (especially his own). These tools (like bcc and bpftrace) are specifically geared towards observability and were not built for security in mind, nor will they be "patched" or fixed for these purposes.
Does this imply that eBPF is a bad foundation for security-focused tooling? Brendan states the following at the close of this blog post:
> There is potential for an awesome eBPF security product, and it's not just the visibility that's valuable (all those arrows) it's also the low overhead. These slides included our overhead evaluation showing bcc/eBPF was far more efficient than auditd or go-audit. (It was pioneering work, but unfortunately the slides are all we have: Alex, I, and others left Netflix before open sourcing it.) There are now other eBPF security products, including open source projects (e.g., tetragon), but I don't know enough about them all to have a recommendation.
> Note that I'm talking about the observability tools here and not the eBPF kernel runtime itself, which has been designed as a secure sandbox. Nor am I talking about privilege escalation, since to run the tools you already need root access (that car has sailed!).
This reads to me that security tooling built on top of eBPF is possible and various organizations are in-flight making it happen (such as Falco[2], Tetragon[3], and Tracee[4]). These teams have recognized the shortcomings of eBPF and are layering other kernel-instrumentation capabilities such as kprobes and LSM hooks into their solutions.
Additionally, the TrailOfBits blog post states:
> Developers need to be aware of pitfalls like probe unreliability, data truncation, instruction limits, concurrency issues, event overload, and page faults. Workarounds exist, but they are imperfect and often add complexity.
These inherent limitations exist primarily because eBPF is a virtual machine within kernel space. Many of these constraints exist because eBPF programs should _never_ lock up the kernel. The eBPF verifier[5] does some checks on the possible code paths the program can take, such as finite bounded loops, null checks on variables, etc. The foundational aspect here is that the eBPF virtual machine is designed to protect the kernel while running programs in kernel space, and that imperfect/complex workarounds may be needed by security-focused projects to respect that foundation.
[1] https://www.brendangregg.com/blog/2023-04-28/ebpf-security-i... [2] https://github.com/falcosecurity/falco/ [3] https:/github.com/cilium/tetragon [4] https://github.com/aquasecurity/tracee [5] https://docs.kernel.org/bpf/verifier.html
Comment · 3 years ago
System76's next flagship, "Virgo," will be in-house designed and has a trackpoint keyboard with a layout will be similar to their line of Launch keyboards [1].
They've been teasing their Virgo prototype [2] [3] [4] on their social media feeds.
[1] https://system76.com/accessories/launch
[2] https://fosstodon.org/@carlrichell/110571781656976874
Comment · 3 years ago
I wanted to chime in here that I agree with (1) as well.
In the time before Chrome, Firefox market share grew in part because of how aggressively Google and the rest of the web advertised for them. However, that market share peaked and shrunk after Chrome was released; Google shifted _all_ of their advertising from Firefox for Chrome.