I prefer a hybrid approach. A document explaining some common things to do and generally the idea behind why the API is structured that way (shows me you actually thought about it, and makes it more logical to find different parts of it without necessarily looking it up), and then an API spec showing all the parameters.
Not to rub it in, but in my forties could be read as almost the entirety of the modern web was developed during my adulthood.
Absolutely nothing... This article literally just says that somebody on an internet forum pointed out that what might happen is that if your account has been around longer than the average lifespan then they'll investigate and maybe terminate it after determining it's no longer owned by the original account owner. Valve today doesn't have the support capacity to perform this kind of investigation. Valve in 50-60 years will be an entirely different beast. This speculation means nothing.
From the stories I've heard from corporate software employees, this does sound like exactly the kind of thing you gotta do to show some manager the guy is buddy-buddy with that they're actually not doing their job. And even then they didn't listen.
We have to work under the assumption that most development is done by inexperienced or, to put it bluntly, bad programmers. I would MUCH rather have bad JS code than bad assembly. One may crash a single tab in my browser, the other may crash my entire computer.
Eh, it's pretty useless without the subscription anyway
This level of effort is probably geared more towards those who create the torrents, not those who consume them.
Assuming you put everything important in home, that is...
It's the quickest way to prove to yourself that you know what you're doing... Most of the time, anyway...
And the of is an optional field for if they have an onlyfans
Testing scams
Any non-scams yet? Or is it safe to assume anything that looks like a scam, is one?
Computer monitors are significantly more expensive for the same size and are overkill for the applications TVs are generally used for.
I'm imagining a scenario where you're working on a feature that changes the DB state (e.x. introduces a new DB migration that changes some columns) and the bug is on an unrelated part of the code from your feature. In this hypothetical, going back to the state of the upstream branch would make your local environment non functional, and the bug is on an unrelated part of the code. Fairly specific scenario but hey, you can worktree for that. It's not particularly thorough, though.
I think they meant "all of this is what might happen next"
But yeah even then social media will still continue to somehow have an ever increasing number of "users"
I sympathize with this. People on the spectrum already have a hard time just living, then they have the extra hurdle of having a hard time communicating their hard time. It feels very human to want to hide the struggle, it makes you feel more like you belong in the world and that you are just one of the other billions out there being "normal" and doing "normal" things. That's a longing that I've felt, but I'm fortunate enough to not have felt it to the degree your father seems to have. I hope you and your brother find a way to get through to him.
I have an Ubuntu server with two network interfaces - an ethernet and a WiFi network let's call eth0 and wlan0. So far I've been able to set it up as a router by enabling packet forwarding and then doing some iptables trickery. These are my iptable commands:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i eth0 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
If I'm understanding correctly, the first command says "if you receive packets from a device, do NAT and then forward them with your IP", the second one says to forward packets from eth0 to eth0, and the last line says "if you get packets back, only accept them if a connection has already been previously established". This Ubuntu server is connected to a router which is connected to a modem that actually has internet access. I've set it up so that my router uses my Ubuntu server as the default gateway during DHCP requests. This works fine, I'm able to use devices to connect to the internet, and if I do a trace route, it first goes to the Ubuntu server, then to the router, then out into the great beyond.
Now, I've run:
iptables -D FORWARD -i eth0 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT iptables -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Which, if I'm understanding correctly, should forward packets through to the WiFi interface instead, but it isn't working. I'm still able to access other devices on the network but not the open internet. I also tried doing iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE which as far as I can tell is unnecessary, but that didn't do anything. When I do trace route this time, it is able to get to the Ubuntu server but no further. I've also tried doing iptables -L -v but neither the wlan0 -> eth0 rule or the reverse have any packet count. I also tried doing iptables -A FORWARD -i lan0 -o wlan0 -j LOG --log-prefix "FORWARD: " to just log it first, but nothing shows up in /var/log/syslog even if I try to connect to the internet from a device.
I'm at a loss here so any help even debugging or if I'm going about this wrong would be greatly appreciated. My ultimate goal is to set up a failover so that if the LAN interface doesn't have a connection, it'll start sending packets through the WiFi interface which will be connected to a different internet connection.
I have a fairly old router that doesn’t support gigabit. I also have a network switch that does support gigabit. If I connect two devices directly to the switch, then connect the switch up to the router, will the connection between the two devices support gigabit? If I’m understanding correctly the router would just act as DHCP server and give the two devices a local IP address, but the actual connection between them wouldn’t go through the router at all.