Posts by pyrolagus@cmpwn.com
(DIR) Post #9jYMyRL2Q8OYERk7vM by pyrolagus@cmpwn.com
2019-06-06T00:33:14Z
0 likes, 0 repeats
@sir emacs
(DIR) Post #9jkLmjuHmz6IHybd1k by pyrolagus@cmpwn.com
2019-06-11T19:17:08Z
0 likes, 0 repeats
@sir @jb55 I don't think you can compare Haskell with yacc. The people at GitHub working on semantic explained why they use Haskell[1], and I doubt that they'd be better off with yacc+C.Also, pandoc is a beast with support for almost every widely used document path. This is less a problem with Haskell, and more a problem with using a less featureful doc generator like haddock, which is actually the standard tool used for GHC and supported by Hoogle. Actually, pandoc isn't even a documentation generator but rather a document converter, so I'd imagine that haddock is still used to generate the docs and then pandoc to produce PDFs or something, in which case it *should* be an optional dependency.[1] https://github.com/github/semantic/blob/master/docs/why-haskell.md
(DIR) Post #9jz8Ue2KUXHOpxoCEi by pyrolagus@cmpwn.com
2019-06-18T22:14:27Z
0 likes, 0 repeats
@sir I don't know. Genode seems fine. Granted, it's a custom subset of C++17, but I'd say it's still C++. Although, I guess the fact that they went with a special subset does speak against C++, but I'm not sure which language would've been better. Maybe C#, maybe Ada.
(DIR) Post #9k5bL5riEW57rzOrZ2 by pyrolagus@cmpwn.com
2019-06-21T22:38:19Z
0 likes, 0 repeats
@byllgrim @sir Emacs, at least in theory, is minimalistic (and definitely elegant) in it's own way. It's kind of just an Elisp interpreter with some stuff that allows it to interface with the OS, so it can be used as an actual editor. I also wouldn't say that extensibility is in conflict with minimalism.I think the problem with Emacs is probably the cruft it's carrying around, but I don't mind it. There's loads of really good tools that integrate nicely with the editor,and pretty much everything is scriptable since Emacs is essentially just an Elisp interpreter after all.Also, features are what people use, and you can allow feature-richness while adhering to minimalism, which is what I think Emacs is striving for.
(DIR) Post #9k6pzEckgGt58NOh3g by pyrolagus@cmpwn.com
2019-06-22T15:33:51Z
0 likes, 0 repeats
@byllgrim First of all, most of those other languages (those that aren't ansic or elisp) are just files for testing, and some are support scripts. Second, vis is a new project, so of course it doesn't have cruft. Emacs is 43 years old, and it supported, and perhaps still supports, computers much older than me. I do think that a modern and clean rewrite of Emacs would be nice, but that's a huge undertaking. Many tried, and many failed.
(DIR) Post #9kyf5zOLlMzGFmyZ72 by pyrolagus@cmpwn.com
2019-07-18T14:51:29Z
0 likes, 0 repeats
@sir @ignaloidas It'll get mbox support though, right? So notmuch/mu would pretty much cover the client-side filtering use case imo. And they're much more powerful than naive server-side filtering into folders.
(DIR) Post #9mkWasGCqQdou8juro by pyrolagus@cmpwn.com
2019-09-09T14:54:05Z
0 likes, 0 repeats
@sir If you're going to lump together Haskell and Erlang, you may as well just lump together C and C++.
(DIR) Post #9nFsotedVlRZ70j5nM by pyrolagus@cmpwn.com
2019-09-24T17:59:29Z
0 likes, 0 repeats
@sir Blindness. Linux accessibility for blindness is a joke.
(DIR) Post #9nIIzUEvTWGmqRNu6q by pyrolagus@cmpwn.com
2019-09-25T22:02:08Z
0 likes, 0 repeats
@sir I've got a point though. The entire Linux ecosystem is so fragmented, and many devs don't even bother to use xdg dirs rather than hardcoding paths. And the GUI situation is so much worse. Good luck getting them to write accessible software. (Although I guess it's fine if you just stick to GNOME stuff.) And the application ecosystem isn't the only shitty thing. Apparently, the audio is so shitty and laggy that it's hard to use screenreaders at high speeds without custom compiling a linux kernel with libsonic and tuning the shit out of it.I'm already not a fan of the moralizing stuff, but some people really don't have much of a choice.
(DIR) Post #9nLg50KkSVywFZaUzI by pyrolagus@cmpwn.com
2019-09-27T13:05:02Z
0 likes, 0 repeats
@sir @martijnbraam Have you tried iwd?
(DIR) Post #9nj5qIEY5wwHPrXKPw by pyrolagus@cmpwn.com
2019-10-08T20:11:46Z
0 likes, 0 repeats
@sir @martijnbraam Doesn't that have possible privacy implications, or are they not inlined?
(DIR) Post #9p7m1FpZzs7jkeLvsm by pyrolagus@cmpwn.com
2019-11-19T15:49:18Z
0 likes, 0 repeats
@sir @minus @martijnbraam Link your screenshots from fbcdn.net, y'all.
(DIR) Post #9qR3iICWO64pQ1HAeW by pyrolagus@cmpwn.com
2019-12-28T20:59:10Z
0 likes, 0 repeats
@sir I'm 22, so there's absolutely no element of nostalgia there.
(DIR) Post #9qVO532PhlRSldW2nA by pyrolagus@cmpwn.com
2019-12-30T23:06:27Z
0 likes, 0 repeats
@sir What would be the best method for tamper-resistance then?
(DIR) Post #9qVOwKQjlsU23ZIbmC by pyrolagus@cmpwn.com
2019-12-30T23:16:41Z
0 likes, 0 repeats
@sir any reason?
(DIR) Post #9qWJrXMnwO0M7NJcjA by pyrolagus@cmpwn.com
2019-12-31T09:54:29Z
0 likes, 0 repeats
@sir @alexbuzzbee I dunno, it seemed to work well when the FBI ordered Apple to unlock an iPhone. And even now it seems they can only break into iPhones 5C and older. Saying that it's impossible to defend against physical access seems pretty arrogant to me as this is as much a physics and electronic engineering question as a software engineering question.
(DIR) Post #9qYzj7zYz74jUf2Mi0 by pyrolagus@cmpwn.com
2020-01-01T16:52:25Z
0 likes, 0 repeats
@sir @alexbuzzbee That doesn't protect you from bootup stage malware, which could just extract any passwords and keys necessary for decryption. But of course, I guess you could always just consider your laptop compromised if it leaves your sight and scrap it for a new one.
(DIR) Post #9qZ1vVcv8XN2B9TgP2 by pyrolagus@cmpwn.com
2019-12-31T09:55:16Z
0 likes, 0 repeats
@alexbuzzbee @sir They CAN take control away from the user, but that obviously depends on how they are used. You could say the same thing about encryption algorithms.
(DIR) Post #9qZ1vWBf3N9xutjQYK by pyrolagus@cmpwn.com
2019-12-31T13:12:49Z
0 likes, 0 repeats
@alexbuzzbee @sir The usbarmory[1] allows you to "burn" a private key for secure boot into the hardware. The user has full control, but it's an irreversible process that prevents tampering. One could argue that this process takes control away from the user because they can't change the private key afterwards, but that would be a dumb argument, since the user chose to do so in the first place.Now, granted. You will have to either keep the private key safe somewhere (which can be near impossible depending on your threat model) or you set up a system that you're confident is secure and satisfactorily configured and destroy the key. Neither is very user friendly, of course, but IMO the important thing is having the possibility to make your system tamper proof.Apple doesn't Linux on the iPhone, so users can't install Linux on their iPhones. If you want security and convenience, the iPhone is a fantastic choice, but if you want the freedom to install whatever you wish, then it's obviously not.[1] https://github.com/inversepath/usbarmory/wiki/Secure-boot-(Mk-I)
(DIR) Post #9qZ1vXClGldN4bFouG by pyrolagus@cmpwn.com
2020-01-01T16:57:34Z
0 likes, 0 repeats
@alexbuzzbee @sir > User-friendliness is an important part of user control.I think that's a memo the open source community has yet to get. At least up till now, it's always been about providing users with all the tools necessary to do whatever they want, even if you have to be a wizard to use those tools.> This is exactly the ethical concern with tamper-prevention;It's a tool that can be used for good and bad. We have those since the beginning of humankind. In this case, the bad isn't disastrous enough to advocate burying this tool. And the good is actually really useful enough. Like, can save lives useful.