> Game Arts subsequently ported Grandia to the PlayStation, dropping it in Japan in the summer of 1999.
When I grew up, "dropping" something meant "excluding" it; you might drop a player from a team or a feature from a product to exclude it. It turns out that Grandia did actually release in Japan for the PlayStation in 1999.
Am I the only one who struggles with this new, fangled definition of the word "drop"?
I thought it was from some music subculture. I first encountered it in the context of albums, around the early or mid 2010s.
I think it’s kinda lame in its escaped-containment form, and am surprised it’s been one of those things that stuck around as long as it has, but would place it low on my list of language gripes, personally.
- Intel quietly introduced their implementation of amd64 under the name "EM64T". It was only later that they used the name "Intel64".
- Early Itanium processors included hardware features, microcode and software that implemented an IA‑32 Execution Layer (dynamic binary translation plus microcode assists) to run 32‑bit x86 code; while the EL often ran faster than direct software emulation, it typically lagged native x86 performance and could be worse than highly‑optimised emulators for some workloads or early processor steppings.
I seem to remember that "runderwo" was working on porting Linux to the N64 back in the "Dextrose" days, when the N64 scene was still active. I can't find much information on his port, but I did find a reference to it here: http://n64.icequake.net/#projects
You/I wish; no, it's just some posts that win the front-page lottery and the rest get flagged, and if flagged enough times (or by enough karma?) they get marked [dupe] by (presumably) dang
In the case of split lottery, someone emails hn@ycombinator.com and one setq [or update statement] later the threads get merged
I haven't done much with HTML for years so I had no idea that modern browsers use "_blank" to open a page in a new tab instead of a new window. This genuinely surprised me, seems like unexpected behaviour or a regression/bug. :)
Nice idea and something I would have otherwise liked to have tried out (I actually have two pairs of DK bongos) but its Windows only and it seems to be closed source. I searched high and low but I couldn't find a link to the source code or even the software licence. :(
Konga Beat uses a paid Unity extension which limits my ability to share the source code in a public repo. The code is also, admittedly, a bit messy. That said, I am happy to share the project's source code if you'd like to check it out! :)
This sentence does not give me confidence. A general purpose sandbox should be implemented in the kernel. The kernel syscall interface will always remain available regardless of any sandbox that has been implemented in user space.
EDIT (to answer a few of the replies here):
The description lacks details so it's not entirely clear how Syd is intended to be used or who its target audience is. If this is intended for a security conscious user to wrap their own executables, similar to Firejail, I guess this serves a purpose but I would certainly hesitate to suggest that it is the "most sophisticated sandbox for Linux". We already have kernel-based SELinux, AppArmor, other LSMs and grsecurity which can ensure that every single executable will run in a sandbox regardless of the experience of the end-user, something a user space wrapper cannot achieve. It's not about whether or not it uses kernel facilities but about ensuring that absolutely everything will be sandboxed.
With seccomp, you have syscall filtering. The bits that are left exposed are largely around mm, and depending on how the sandbox works, non-syscall APIs like io_uring. It essentially actuates kernel APIs to sandbox, and then redirects a number of APIs to use userspace reimplementations.
I'm not sure this is correct, I suspect this works on a similar principal as something like gvisor where as I understand it syscalls are redirected to another userspace program. In gvisors case the kernel basically get's re-implemented in user-space to provide the secure container like implementation.
Also, as I recall some of the kernel based syscall based sandboxing have had a number of issues with dealing with some of the syscalls.
It's a bit non-obvious from that description but Syd does in fact use kernel facilities to do the sandboxing. A sibling comment links to some better documentation (the syd man page) that explains what it uses https://man.exherbolinux.org/syd.1.html
1) Seccomp, a BPF based kernel filter for syscalls
2) Bind mounts inside a filesystem namespace to control what files are visible
3) Landlock - more path restriction type stuff and permission changes to paths that are local to the application being wrapped
4) seccomp-notify (used with ptrace to inspect types of arguments to syscalls that bpf isn't allowed to access for security reasons, i.e. pointers)
But being open source means that one could fork AOSP. Also the Google proprietary stuff comes with the Play Services, not AOSP.
So AOSP is a lot better than the alternatives, I would say.
I have a different feeling about Chromium: it is open source, but through it Google gets to control the future of the Web. But Android is not a standard, it's "just" one OS, so changes made by Google in AOSP don't really impact, say, iOS.
> But Android is not a standard, it's "just" one OS, so changes made by Google in AOSP don't really impact, say, iOS.
That's interesting because I personally do believe that Android is kind of the mobile standard, it has everything to be one, from the wide variety of devices to the certifications of conformity.
When I grew up, "dropping" something meant "excluding" it; you might drop a player from a team or a feature from a product to exclude it. It turns out that Grandia did actually release in Japan for the PlayStation in 1999.
Am I the only one who struggles with this new, fangled definition of the word "drop"?