251–260 of 309 posts
People... Please stop using foreign alphabets like that! It's a nightmare for those of us who know the alphabets. It took me a good 20 seconds to read the title. And it's magnitudes worse when someone uses cyrillic for instance and it's native to me.
cute title; but not searchable, machine translatable, or screen-reader friendly.
Earlier quoted context omitted.
there are more recent patents involving extensions on x86_64 which are essential for more modern processors, I believe.
Yes, being x64 compatible but not supporting SSE4 or AVX is basically useless.
Earlier quoted context omitted.
Yup, that matches my experience running the example (I also had to put it in $PATH for the command -v in the header to work). I built program.com myself and it seems to be missing the DOS header for some reason, so it just doesn't execute at all…I'd file a bug, but I have no idea if she is interested in supporting it or if I can provide any useful information besides "it doesn't work".
Glad to hear you're using it! You can ping me on Google Hangouts (jtunney@gmail.com) for help. We also might be able to set up a Slack or IRC channel to iron out these issues. I actually didn't post this thread because I was still working on fixing the long tail of minor bugs. But now that the project has caught everyone's attention, we might be able to fix them sooner!
> I believe the best chance we have of doing that, is by gluing together the binary interfaces that've already achieved a decades-long consensus, and ignoring the APIs. Yeah, this isn't going to fly for OpenBSD, which doesn't have ABI stability, programs are expected to use libc. Program for the API, not the ABI. The author is clever, but misguided.
Earlier quoted context omitted.
Oh, cool! I thought this file was just prefixed with some random garbage. Unrelated: I used this to verify that my daily scheduled full scan of my Linux laptop works. This is required by compliance at $WORK. It reports found viruses via the i3-nagbar.
Linux has antivirus software written for it? TIL.
Usually, linux antivirus software is not designed to protect the machine itself, instead it is more commonly used by mail and file servers to protect windows clients.
Earlier quoted context omitted.
Not GP, but I'll take a crack at this. The stupid game would be making your article title not an immediately obvious summary of your article. The stupid prize would be this HN thread now that is only discussing the title, instead of the actual article.
Which, I would argue, says at least as much about the HN crowd as it does about whoever posted the article under this specific title. EDIT: more specifically .. it's rather ironic how judgmental (and honestly: pretty darn pretentiously) so many here instantly get, yet how there is this implied assumption that the collective wisdom and judgement of this community is above criticism itself, somehow. It might say far mo…
> If a microprocessor architecture consensus finally exists I don't think that's a good goal to have. Without competing architectures we'll enter a microprocessor dark age. Although the glory days of Alpha and IA64 are over, plenty of that experience was used to bolster today's instruction sets. Diversity is a good thing.
I'm not sure I buy that, you can have a lot of competition on the same ISA. After all on the desktop/server x86 has been king for a while, and on embedded architectures ARM has all but taken over the competition. Yet there's significant competition on both fronts. Meanwhile attempts at creating new ISAs over the past couple of decades has been met with relatively little success, or only in very specific niches. Itani…
Just my opinion, but SiFive has been a huge driving force in even giving RISC-V a shot at breaking into server space. Most other companies (Google, Nvidia, Western Digital) have invested in RISC-V with the apparent intent of focusing on building microcontrollers/embedded processors. AFAIK, there's only one player who is investing in building RISC-V server-class CPUs and that's SiFive.
Please correct me if I'm mistaken! I've been following RISC-V pretty closely for the last year or so and there's quite a lot to catch up on.
1 = https://github.com/riscv/riscv-v-spec 2 = https://github.com/riscv/riscv-plic-spec
Earlier quoted context omitted.
Indeed. The Win32 API (and UWP et al) is the only one that's officially stable. Kernel syscalls themselves are entirely unstable. Not even just the numbers but the calling convention and everything else. Microsoft reserves the right to add, remove or modify anything in or exposed by the NT kernel. Of course they won't do so frivolously but syscall numbers are especially prone to change with a new build of the kernel.…
Go tried to break the rules and call macOS syscalls directly (like they do on Linux, because Go is a massively NIH language so they don't use libc where they can get away with it) and it bit them hard when an OS update broke all Go apps.
Apple came back in the late nineties, in part, because they copied and pasted the magic numbers from the Bell System Five codebase, e.g. 1 for exit(), etc. Capitalizing on UNIX popularity helped Apple succeed. So they shouldn't treat Bell Labs technologies like it's their own implementation detail.
For example, Microsoft has the right to break NTDLL because they invented it, and never intended for it to be used directly by app developers. Windows was designed from its beginning to have dynamic system interfaces too. In the UNIX community, DSOs have always been extremely controversial, since they raise legal questions compared to SYSCALL and INT trapping, and they violate the ability of a program to assume complete control of the full virtual address space.
If Apple devs are reading, then please, we love your products, but we don't love DSOs. Please grant us the freedom to choose. Please keep SYSCALL stable. It'd also be great if you didn't add special-cased code to XNU that blocks open source Actually Portable Executables, like you did with UPX. Email me (the author) your feedback instead. I'll do anything to help, short of adopting a second WIN32 linkage model.
Back when all you had was minicom dialing a BBS, there was a chicken and egg problem where you needed uudecode to decode any executable you downloaded. If you did not have uudecode you were stuck. If you are unfamiliar, unencoding a file allows you to send binary data through text transmission. Then a clever version of a DOS .COM file was posted which implemented uudecode, but it only used x86 instructions that were…