HackerTrans
TopNewTrendsCommentsPastAskShowJobs

halosghost

no profile record

comments

halosghost
·3 個月前·discuss
See also, one of the older / more-robust entrants in this space [0], and one of the more innovative (still from a hot-second ago now…) [1].

All the best,

0. https://github.com/andmarti1424/sc-im

1. https://www.syntax-k.de/projekte/teapot/
halosghost
·5 個月前·discuss
https://unbiassly.com/terms_of_service is 404.

All the best,

-HG
halosghost
·7 個月前·discuss
I flagged this as undisclosed slopware being pushed as secure cryptographic engineering with no reasonable measure of human review.

All the best,

-HG
halosghost
·8 個月前·discuss
I flagged this as heavily-clickbaited self-promotion.

All the best,
halosghost
·8 個月前·discuss
Just to say, I actually disagree entirely. I do not believe press releases are, almost ever, valuable. Papers are just a format (with some writing style conventions that tend to follow the given field-of-study); they may be intimidating for many, but the hacker spirit and ethos is to dive in and tackle it, and that will pay far more dividends for everyone reading it than to consume more advertising. :)

All the best,

-HG
halosghost
·8 個月前·discuss
Hey @dang (I know it doesn't work, but isn't it fun to use your imagination?), can we get this press release replaced by a link to the actual paper [0]? This one is even open-access!

All the best,

-HG

[0] https://www.nature.com/articles/s41467-025-64982-y
halosghost
·9 個月前·discuss
Kentucky Route Zero [0], which managed to not just be beautiful in its own right, but so perfectly captures the visual language it's aiming for that you'll just lose yourself in moments of experience.

Also, Pathologic 2 [1] (probably, if you have more fortitude than me, maybe the original or HD remaster are of value [2]).

All the best,

-HG

[0] https://www.gog.com/en/game/kentucky_route_zero

[1] https://www.gog.com/en/game/pathologic_2

[2] https://youtu.be/JsNm2YLrk30
halosghost
·10 個月前·discuss
From `/usr/share/X11/locale/en_US.UTF-8/Compose`:

    ...
    <Multi_key> <less> <apostrophe>     : "‘"   U2018 # LEFT SINGLE QUOTATION MARK
    <Multi_key> <apostrophe> <less>     : "‘"   U2018 # LEFT SINGLE QUOTATION MARK
    <Multi_key> <greater> <apostrophe>  : "’"   U2019 # RIGHT SINGLE QUOTATION MARK
    <Multi_key> <apostrophe> <greater>  : "’"   U2019 # RIGHT SINGLE QUOTATION MARK
    <Multi_key> <less> <quotedbl>       : "“"   U201c # LEFT DOUBLE QUOTATION MARK
    <Multi_key> <quotedbl> <less>       : "“"   U201c # LEFT DOUBLE QUOTATION MARK
    <Multi_key> <greater> <quotedbl>    : "”"   U201d # RIGHT DOUBLE QUOTATION MARK
    <Multi_key> <quotedbl> <greater>    : "”"   U201d # RIGHT DOUBLE QUOTATION MARK
    ...
    <Multi_key> <minus> <minus> <minus> : "—"   U2014 # EM DASH
    ...
I genuinely do not understand how compose-lacking ɪᴍᴇs continue to see use—so much more of the full unicode spec is trivially available to you… even quite intuitively.

All the best,

-HG
halosghost
·去年·discuss
Note that this is actually one of the things Anubis does. That's what the proof-of-work system is, it just operates across the full load rather than targeted to a specific user's load. But, to the GP's point, that's the best option while allowing anonymous users.

All the best,

-HG
halosghost
·11 年前·discuss
Actually, that's why I happily offer to help those who are interested in learning C to come and ping me with code snippets and to even assign them exercises and walk through them step by step with people. The world needs more competent C programmers, and if I can help with that at all, I'd like to :)
halosghost
·11 年前·discuss
Personally, I have found most C books to be colossal failures. K&R is a great text that would be good for you to read eventually (if only to see how far C has come), but to learn how to do modern programming, K&R probably is not where you should go.

Additionally, LCTHW let me down significantly (regardless of what you think of the author).

If I could make two recommendations to you, the first would be that reading a text book will never make you good at C programming; like many other languages (or perhaps programming in-general with the exclusion of highly-academic languages), creating your own personal projects and learning as you go with a mentor to guide you is probably the single best way to become proficient.

Second, eventually, you should read the current Spec (or at least, the latest draft and all its TC). Before getting to that, if you are convinced that a text book would be helpful, go look at http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

All the best,
halosghost
·11 年前·discuss
I understand that it is available simply; I was questioning the logic of having it disabled by-default. Having the ability to do run-time checks for {over,under}flow does seem to make this issue a little better but doesn't explain the logic of having the language prefer UB by-default.

Yes, C does this too (integers are signed by-default), but if I'm shopping for a language that abstracts C, I'm probably looking for improvments over C's defaults.
halosghost
·11 年前·discuss
Okay, so I'm having one problem with nim. Disabling all unsigned arithmetic by-default. The logic is actually fairly sound (it's probably, generally, harder to overflow a signed than an unsigned), but nim doesn't compile to object code; it transpiles to C and then C compiles to object/machine code.

Edit: it's obviously much harder to overflow an unsigned than a signed; in the sentence above, I was thinking particularly of underflow (which is what the nim devs reference as their logic for disabling unsigned arithmetic by-default).

The problem here is that unsigned arithmetic, though much easier to hit underflow, is fully defined in C where signed {under,over}flow is UB. As a result, if you manage to hit this case in nim, you're now going to hit UB by-default. This seems crazy to me. Am I missing something?