Hacker Newsnew | past | comments | ask | show | jobs | submit | more jlgaddis's commentslogin

I almost want to ask if this is a real question.

Obviously, things have changed since then, but there was a time that not everyone had 24/7 always-on access to the Internet. Really, that's only a recent thing. How do you think programming took place -- across a generation or two -- before then?

In my case, it was 1999 before I was able to get an Internet connection that wasn't dial-up Internet -- but I lived in a small, rural town in the midwest, not in a major city. I was the first person in our area (perhaps a 30 mile radius) to have an "oh-my-$deity-this is-so-amazingly-fast" 768k/128k DSL line (besides the two guys who ran my ISP) as I knew them and they asked if I would, effectively, be a "beta tester" to make sure things were working as they 2were supposed to be before they started offering the service to customers.

So, yeah, before then it was possible to program without a Internet connection. That was the "default", normal situation, in fact. We had (dead-tree) books, for example, and could telephone other people, there was FIDOnet ("before Internet"), Usenet ("after Internet"), e-mail and mailing lists and, eventually, even the web (from 1991 on, of course). Plenty of programming happened without Internet access before then (in fact, all of it did, basically).

Of course, some programming is more complicated nowadays, when you need a library for every little thing you do, so I suppose programming without an Internet connection might not be possible if you need to download a library for for .. loops or something.

(By the way, when I was in high school, I'd write code on paper (whatever program I was working on at the time) while sitting in class. When I'd get home after school, then I could type it in on the computer.)

Of course, if you are one of those "programmers" who have to stop and Google something afte every five lines of code, well, it's probably not possible.


> The exact number of U.S. residents who potentially had their information reviewed isn’t known because there’s no precise way to measure the data, according to the report.

How convenient.


For the FBI or bloomberg?


For the FBI.


I'm (not) looking forward to the future data breach notifications / post-mortems that include something like "... our developers used a tool to copy the production database to a dev database on their laptop ..."

Honestly, I'm kinda surprised by the lack of comments advocating against doing this.


> That's probably too limited actually. Because you can have a whole bunch of stuff in PAM: LDAP, OTP, Yubikeys, and all kinds of other fancy modules. Doesn't seem that unix_chkpwd handles any of that.

Yes, you're right. unix_chkpwd doesn't handle any of that and, in fact, was never intended to handle any of that -- and that's the entire point!

The entire design of PAM is, well, to have separate "modules" that are "pluggable" depending on how you need to handle "authentication" -- LDAP, OTP, Yubikeys, etc.

That is, the pam_unix module (which uses unix_chkpwd) is used when you enter in your (local user account's) password. If you're using something else -- LDAP or NIS or whatever -- for user accounts (i.e., your "passwd" database) there are separate (PAM) modules for that!

> Also, I still think it has to be a network service, ...

No, it really doesn't and, besides, there are other alternatives that would be much better to use instead of a network socket (such as a local UNIX socket, for one).

I really try not to make such remarks here on HN, but in this case it does seem that you have a fundamental misunderstanding of just how this stuff works (which is almost certainly why you're comment has been so downvoted).


Let me guess: your company ultimately profits somehow, whether directly or indirectly, from the use ("sale", presumably) of these "decentralized domains" and/or ".eth DNS"?


> "... to prevent PRN code duplication and avoid using codes with poor properties that may interfere with receiver performance." (https://www.gps.gov/technical/prn-codes/)


> ... but RTK GPS (where solely atmospheric errors are reduced via local knowledge) gets accuracy down to about ±0.1 meters.

My understanding is this is also possible with GNSS receivers which can use satellites on more than one system or on more than one frequency band (e.g., the GPS L1 and L5 signals) at the same time, as this allows any atmospheric issues to be taken into account when making positioning calculations.

I don't know if any of the cheap, commonly available "multi-GNSS" receivers actually make such adjustments / corrections or if one would need to "upgrade" to one of the (much more expensive, naturally) "RTK-capable" receivers.

(My interest is primarily in timing so I mostly stick with GPS-only units which support fixed position mode, so I haven't bothered to keep up with the newer stuff, such as RTK.)


None of the non-rtk ones approach this accuracy solely because without knowing the varying local atmosphere error you cannot, even in theory, get that accuracy from GPS.

All the GPS and RTK systems I've been working on use all possible signals from all the GNS systems (except I disable Russian GLONASS at the moment due to war fueled sketchiness). To get them to work well you need good antennas that capture them all, and good wiring to keep phases clean. Noise kills precision here.

Find a textbook that does all the math and physics behind all the GNS systems, and you'll find a chapter on errors introduced by atmosphere.

RTK gets around this by having a known nearby (and hence nearly identical atmosphere path) point also get all the GNS signals, do the same computation, and send correction data in realtime to your RTK receiver.

There's also some neat stuff about signal phase that adds a little more precision over standard GPS.

I've now built multiple complete RTK and multi-RTK systems, and have been up and down all the stacks from many angles, working on pushing things to the limit, for industrial uses.

RTK really goes beyond anything I've seen in GPS, at any price. There's simply no way to realize all your signals are delayed or bent by local ionized or magnetic storms causing signal delay without some other truth data.


> You can also git your /etc of course.

You can and you should, in my opinion.

However, you really want to use "etckeeper" [0] to do that (as opposed to "maintaining" /etc as a git repo, manually, yourself).

---

ETA:

Seriously, look over etckeeper's README file [1] and/or man page [2]. Next, go read a couple articles or blog posts that describe "How-To store /etc in a git repository on debian linux" [3]. Then, if you're a sado-masochist, go ahead and actually try it that way for a while. Finally, install etckeeper, spend two minutes setting it up (if your packaging tool didn't do that for you automatically), and almost instantly regain your sanity!

---

[0]: http://etckeeper.branchable.com

[1]: http://etckeeper.branchable.com/README/

[2]: https://man.archlinux.org/man/etckeeper.8

[3]: http://hyperprog.com/howto/etc-git.html


You certainly don't miss an opportunity to make a meaningless, no substance comment just so that you can spam a link to some "project" of yours, do you?


> Sigh, I was just thinking of moving all my stuff, projects and even websites from cloud hosted solutions to my own home server ...

Good thing you didn't follow the other link to the changes in pricing for (egress) network traffic!


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: