HackerTrans
トップ新着トレンドコメント過去質問紹介求人

snuxoll

no profile record

コメント

snuxoll
·先月·議論
I really don't think Rust does, but that's if you're outright refusing to use `unsafe` anywhere. Might be a little noisier if you're using things like ManuallyDropped instead of just using raw pointers, but the language doesn't stop you from doing things in ways you would with C or C++, it encourages you to encapsulate the hard parts so you can worry less about correctness of 98% of your codebase, instead of fearing incorrect behaviors can silently sneak in.
snuxoll
·4 か月前·議論
> Now that everything is using the same silicon, it costs Apple very little to maintain all these variants (that are mostly binning), so there's little reason not to.

Don't underestimate how much of a bitch it is to maintain all the separate SKUs. This isn't the old CTO days where you had: 1 chassis, N mainboards for different CPU/GPU combinations, a bunch of SODIMM's of varying capacities, and a couple of different fixed storage drives to toss in.

When any given MBP has 2 CPU/GPU options, multiple memory options, and multiple storage options, with everything being soldered to the board? Honestly, the Neo is the one product in their portable lineup that doesn't cause a massive headache for logistics.

But...even then, Tim Cook is CEO still, and he is a supply chain guy, so you better believe this is top of his list when it comes to their product lineup. You don't increase operational complexity for no reason, because that is where the cost for every product lies for them, it's not just dealing with silicon binning.
snuxoll
·5 か月前·議論
"Because it was a 50-50 shot on whether you'd be going left or right [...]"

Yeah, that about sums up how terrifying it is to give these agents so much access to things.
snuxoll
·5 か月前·議論
> I didn't get meds when I was younger. Now I have top 1% IQ (likely average here on hn), but work as a butcher at a slaughterhouse. My mom didn't want to stigmatise me with a diagnosis.

I really hope I'm not stating the obvious to you here, but don't let your current situation define you like it guarantees the course of the rest of your life.

> But if I had less problems at school, I might've been doing sth more fun now and less demanding on the body.

Even on Adderall in my teenage years, I fucked around in school - it didn't interest me, which is not uncommon in 2e individuals with ADHD. Dropped out at 16, got my GED a few years later, never went to college, resigned myself to the fact that I would be working class like my parents for the rest of my life.

But the right doors opened because I kept pulling at the knobs when I saw them, while the thousands of hours of my free time messing around with dozens of linux distros, writing toy programs for personal use, and a little bit of selling the unique talents my atypical neurology gives me, were enough to get me through one interview, and then the next.

The non-traditional path still very much exists in many fields, but it always starts at smaller companies that are less glamorous to work at, and often don't pay as well. None of us may be entitled to anything, but that doesn't mean we should resign ourselves to wasting our talents because the traditional paths didn't work out for our unique situations.
snuxoll
·5 か月前·議論
Or, alternatively, because many of us have a tendency to eat when we are uninterested in other tasks...simply how much I snack, whether I feel like eating at regular mealtimes, and the correlated impact on my weight, is a pretty big indicator that I need to ask my physician to adjust the dose of my Vyvanse next time I send a message for my next fill.
snuxoll
·5 か月前·議論
It's close enough, because (most of) the encryption keys are wiped from memory every time the device is locked, and this action makes the secure enclave require PIN authentication to release them again.
snuxoll
·5 か月前·議論
Installed mini-splits to replace the propane stove that heated my house, DIY job, so all it cost was the units themselves and some materials.

Propane bill (no natural gas, town of 500) from Oct 24 to Feb 25 (installed the mini splits that month) was $1200, for just heating.

My mini-splits are on a dedicated sub panel with an Emporia Vue 3 energy monitor. $604 in electricity consumption, and that includes air conditioning over the summer months.

For what it’s worth, our winter weather averages 25-35F with the occasional few days dipping to tens, single digits, and the occasional -10 freak; but these units just BARELY have a HSPF4 rating to classify as “cold climate” models. Still going to pay for themselves in 6 years without any tax credits, and 4 or so since I still installed them when they were available.
snuxoll
·5 か月前·議論
The problem of other minds is real, which is why I specifically separated philosophical debate from the technological one. Even if we met each other in person, for all I know, I could in fact be the only intelligent being in the universe and everyone else is effectively a bunch of NPCs.

At the end of the day, the underlying architecture of LLMs does not have any capacity for abstract reasoning, they have no goals or intentions of their own, and most importantly their ability to generate something truly new or novel that isn't directly derived from their training data is limited at best. They're glorified next-word predictors, nothing more than that. This is why I said anthropomorphizing them is something only fools would do.

Nobody is going to sit here and try to argue that an earthworm is sapient, at least not without being a deliberate troll. I'd argue, and many would agree, that LLMs lack even that level of sentience.
snuxoll
·5 か月前·議論
Anyone who anthropomorphizes LLM's except for convenience (because I get tired of repeating 'Junie' or 'Claude' in a conversation I will use female and male pronouns for them, respectively) is a fool. Anyone who things AGI is going to emerge from them in their current state, equally so.

We can go ahead and have arguments and discussions on the nature of consciousness all day long, but the design of these transformer models does not lend themselves to being 'intelligent' or self-aware. You give them context, they fill in their response, and their execution ceases - there's a very large gap in complexity between these models and actual intelligence or 'life' in any sense, and it's not in the raw amount of compute.

If none of the training data for these models contained works of philosophers; pop culture references around works like Terminator, 'I, Robot', etc; texts from human psychologists; etc., you would not see these existential posts on moltbook. Even 'thinking' models do not have the ability to truly reason, we're just encouraging them to spend tokens pretending to think critically about a problem to increase data in the recent context to improve prediction accuracy.

I'll be quaking in my boots about a potential singularity when these models have an architecture that's not a glorified next-word predictor. Until then, everybody needs to chill the hell out.
snuxoll
·6 か月前·議論
> Note that password-based Bitlocker requires Windows Pro which is quite a bit more expensive.

Given that:

1. Retail licenses (instead of OEM ones) can be transferred to new machines

2. Microsoft seems to be making a pattern of allowing retail and OEM licenses to newer versions of Windows for free

A $60 difference in license cost, one-time, isn't such a big deal unless you're planning on selling your entire PC down the line and including the license with it. Hell, at this point, I haven't purchased a Windows license for my gaming PC since 2013 - I'm still using the same activation key from my retail copy of Windows 8 Pro.
snuxoll
·6 か月前·議論
> Pg moves the data between positions on update?

I assume they typo'd "partitions" as "positions", and thus the GP comment was the correct reply.
snuxoll
·6 か月前·議論
Except, you don't.

Assume eth0 is WAN, eth1 is LAN

Look at this nftables setup for a standard IPv4 masquerade setup

    table ip global {
        chain inbound-wan {
            # Add rules here if external devices need to access services on the router
        }
        chain inbound-lan {
            # Add rules here to allow local devices to access DNS, DHCP, etc, that are running on the router
        }
        chain input {
            type filter hook input priority 0; policy drop
            ct state vmap { established : accept, related : accept, invalid : drop };
            iifname vmap { lo : accept, eth0 : jump inbound-wan, eth1 : jump inbound-lan };
        }
        chain forward {
            type filter hook forward priority 0; policy drop;
            iifname eth1 accept;
            ct state vmap { established : accept, related : accept, invalid : drop };
        }
        chain inbound-nat {
            type nat hook prerouting priority -100;
            # DNAT port 80 and 443 to our internal web server
            iifname eth0 tcp dport { 80, 443 } dnat to 192.168.100.10;
        }
        chain outbound-nat {
            type nat hook postrouting priority 100;
            ip saddr 192.168.0.0/16 oiname eth0 masquerade;
        }
    }
Note, we have explicit rules in the forward chain that only forward packets that either:

* Were sent to the LAN-side interface, meaning traffic from within our network that wants to go somewhere else

* Are part of an established packet flow that is tracked, that means return packets from the internet in this simple setup

Everything else is dropped. Without this rule, if I was on the same physical network segment as the WAN interface of your router, I could simply send packets to it destined to hosts on your internal network, and they would happily be forwarded on to it!

NAT itself is not providing the security here. Yes, the attack surface here is limited, because I need to be able to address this box at layer 2 (just ignore ARP, send the TCP packet with the internal dst_ip address I want addressed to the ethernet MAC of your router), but if I compromised routers from other customers on your ISP I could start fishing around quite easily.

Now, what's it look like to secure IPv6, as well?

    # The vast majority of this is the same. We're using the inet table type here
    # so there's only one set of rules for both IPv4 and IPv6.
    table inet global {
        chain inbound-wan {
            # Add rules here if external devices need to access services on the router
        }
        chain inbound-lan {
            # Add rules here to allow local devices to access DNS, DHCP, etc, that are running on the router
        }
        chain inbound-nat {
            type nat hook prerouting priority -100;
            # DNAT port 80 and 443 to our internal web server
            # Note, we now only apply this rule to IPv4 traffic
            meta nfproto ipv4 iifname eth0 tcp dport { 80, 443 } dnat to 192.168.100.10;
        }
        chain outbound-nat {
            type nat hook postrouting priority 100;
            # Note, we now only apply this rule to IPv4 traffic
            meta nfproto ipv4 ip saddr 192.168.0.0/16 oiname eth0 masquerade;
        }
        chain input {
            type filter hook input priority 0; policy drop
            ct state vmap { established : accept, related : accept, invalid : drop };
            # A new rule here to allow ICMPv6 traffic, because it's not required for IPv6 to function correctly
            icmpv6 type { echo-request, nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept;
            iifname vmap { lo : accept, eth0 : jump inbound-wan, eth1 : jump inbound-lan };
        }
        chain forward {
            type filter hook forward priority 0; policy drop;
            iifname eth1 accept;
            # A new rule here to allow ICMPv6 traffic, because it's not required for IPv6 to function correctly
            icmpv6 type { echo-request, echo-reply, destination-unreachable, packet-too-big, time-exceeded } accept;
            # We will allow access to our internal web server via IP6 even if the traffic is coming from an
            # external interface
            ip6 daddr 2602:dead:beef::1 tcp dport { 80, 443 } accept;
            ct state vmap { established : accept, related : accept, invalid : drop };
        }
    }
Note, there's only three new rules added here, the other changes are just so we can use a dual-stack table so there's no duplication of the shared rules in separate ip and ip6 tables.

* 1 & 2: We allow ICMPv6 traffic in the forward and input chains. This is technically more permissive than needs to be, we could block echo-request traffic coming from outside our network if desired. destination-unreachable, packet-too-big, and time-exceeded are mandatory for IPv6 to work correctly.

* 3: Since we don't need NAT, we just add a rule to the forward chain that allows access to our web server (2602:dead:beef::1) on port 80 and 443 regardless of what interface the traffic came in on.

None of this requires being a "network expert", the only functional difference in an actually secure IPv4 SNAT configuration and a secure IPv6 firewall is...not needing a masquerade rule to handle SNAT, and you add traffic you want to let in to forwarding rules instead of DNAT rules.

Consumers would never need to see the guts like this. This is basic shit that modern consumer routers should do for you, so all you need to think about is what you want to expose (if anything) to the public internet.
snuxoll
·6 か月前·議論
> But that's getting rather off topic. The dispute was about whether or not NAT of IPv4 is of reasonable benefit to end user security in practice, not about whether or not typical IPv6 equipment provides a suitable alternative.

And, my argument, is that the only substantial difference is the action of a netfilter rule being MASQUERADE instead of ALLOW.

This is what literally everyone here, including yourself, continues to miss. Dynamic source NAT is literally a set of stateful firewall rules that have an action to modify src_ip and src_port in a packet header, and add the mapping to a connecting tracking table so that return packets can be identified and then mapped on the way back.

There's no need to do address and port translation with IPv6, so the only difference to secure an IPv6 network is your masquerade rule turns into "accept established, related". That's it, that's the magic! There's no magical extra security from "NAT" - in fact, there are ways to implement SNAT that do not properly validate that traffic is coming from an established connection; which, ironically, we routinely rely on to make things like STUN/TURN work!
snuxoll
·6 か月前·議論
> With IPv6 it's possible to fail to configure those nftables rules. The firewall could be turned off.

So what? It's not like you get SNAT without a couple netfilter rules either.

This argument doesn't pass muster, sorry. Consumer and SOHO gear should come with a safe configuration out of the box, it's not rocket science.
snuxoll
·6 か月前·議論
That’s not at all what the child to me was saying in even a generous reading.

But HOT updates are a thing, too.
snuxoll
·6 か月前·議論
NAT-PMP, UPnP, PCP, et. all primarily exist because consumer networks that have to share a public IP face more issues than simply opening a port up to the internet. Destination port conflicts, port remapping, discovery of your public IP, are huge fucking headaches that these protocols also assist with.

Given most consumer routers these days can be configured with a mobile app, I could easily foresee a saner alternative where devices could simply ask the gateway if they could open up a port and have a notification sent to a mobile app to allow it.

But, that said, given how many devices are mobile these days I think the benefit of endpoint firewalls shouldn’t be underplayed either.
snuxoll
·6 か月前·議論
NAT gateways that utilize connection tracking are effectively stateful firewalls. Whether a separate set of ‘firewall’ rules does much good because most SNAT implementations by necessity duplicate this functionality is a bit ignorant, IMO.

Meanwhile, an IPv6 network behind your average Linux-based home router is 2-3 nftables rules to lock down in a similar fashion.
snuxoll
·6 か月前·議論
With partitioning? No you don't. It gets a bit messy if you also want to partition a table by other values (like tenant id or something), since then you probably need to get into using table inheritance instead of the easier declarative partitioning - but either technique just gives you a single effective table to query.
snuxoll
·6 か月前·議論
I care about having a commit log that's useful and easy to scan through, it's not about it being "visually pleasing". Having a dozen "oopsie" commits in the log doesn't make my life any easier down the road, all it does is increase noise in the history.

Again, once something hits `main` or a release/maintenance branch then history gets left the hell alone. But there really is no context to be gained from me fixing stupid things like typos, stripping out printf() debug statements, etc. being in the commit logs before a change gets merged.
snuxoll
·6 か月前·議論
There's a huge divide between abusing rebase in horrible ways to modify published history, and using it to clean up a patch series you've been working on.

Oops, I made a mistake two commits ago, I'd really like to get some dumb print statements I added out before I send this off to get merged is perfectly valid, I just did it yesterday. A quick `git commit --fixup` followed by `git rebase -i --autosquash HEAD^3` and I had some dumb debugging code I left in stripped out.

Then, there's other perfectly valid uses of rebase, like a simple `git rebase main` in an active development branch to reparent my commits on the current HEAD instead of having my log messed up with a dozen merge commits as I try to keep the branch both current and ready to merge.

So, yes, I do think editing history is a grand idea that should be used regularly. It lets me make all the stupid "trying this" and "stupid bug" commits I want, without polluting the global history.

Or, are you telling me you've also never ended up working on two separate tasks in a branch, thinking they would be hard to separate into isolated changes, and they ended up being more discrete than you expected so you could submit them as two separate changes with a little help from `git cherry-pick` and `git rebase` too?

Editing history isn't evil. Editing history such that pulls from your repository break? That's a different story entirely.