So it's not going to work, because they would not need it if people could gone without phone, and people who can't won't stio just because a bunch of other people will tell them it's better.
Social pressure doesn't work with addicts. Espacially if said addict are to a tool that also makes some tasks 10 times faster.
I'm going to call on Cunningham's law here... (I'm not sure if I am right or wrong but I think I'm right and hopefully someone can correct me)
I don't think starlink needs GPS as much as the starlink service is a form of GPS. The base station sees several satellites and the satellites know where they are and so the base station can triangulate where you are, and the whole system requires this precision location mechanism to work, so the 2 way communication is a form of Global Positioning without relying on external GPS data.
Perhaps the base station is also able to use GPS but the starlink communication is also able to do exactly what GPS does so "fake GPS" would do nothing to conceal the base station's location and probably make initialization hard or impossible.
You need a precise clock for any form of GNSS[0] to function. AFAIR StarLink satellites doesn't have precise clock on the board. And anyway, modern GNSS chips are.. $1? Cheaper? No way you wouldn't use GNSS already deployed and working (and you are not paying for it) in a commercial product.
[0] GPS is GNSS, it's just in America GPS became the synonym for GNSS
> You need a precise clock for any form of GNSS[0] to function
How precise? I assume that inaccuracy in the clock produces imprecision in location - how much time inaccuracy produces how much location inaccuracy?
> And anyway, modern GNSS chips are.. $1? Cheaper? No way you wouldn't use GNSS already deployed and working (and you are not paying for it) in a commercial product.
Rather than using the Starlink satellites as an alternative to GPS - get a location fix using both Starlink and GPS, and compare them. Even given the former is going to be significantly less accurate - suppose GPS is accurate to within 5 metres and Starlink is accurate to within 5000 metres - well, if the two differ by 50,000 metres, you know something is going wrong, and the terminal might decide to disable itself in such a situation.
GNSS satellites orbits are between 20000km and 30000km. 20kkm is 0.06671s of c, 30kkm is 0.10007s, 5km is 0.000016678. So a very precise, that's why they have an atomic clock on board instead of cheap quartz one.
> if the two differ by 50,000 metres, you know something is going wrong
Like what your imprecise methods give you a very rough estimate where is the terminal and your legitimate customers in the nearby areas (not even doing anything for or against) are saying thanks for their shut off terminals.
So -- for the purposes of locating a base station that's connected to the starlink network -- the starlink network would rely on the base station reporting it's location? Hopefully not... It certainly doesn't need to just trust it when it has direct observation available too.
I'm not suggesting that whatever GPSish thing you'd be able to get out of a pure starlink protocol communication would give you super resolution, but it'd certainly be enough to identify "Crimea" vs "Indian Ocean".
And as far as base station -> constellation -- putting a GPS receiver in it is of course smart to speed that up, but I'm not sure even that's necessary or just helpful.
Also the attitude matters a lot. If it comes from creativity, joy, fun, etc., it will work way better than if it comes with distanciation, opposition and awkwardness.
Context is important, but what you bring as well.
I have friends that can make a new pair of glasses uneasy, and some that can rock devils horns on a tuesday.
Yeah. I certainly understand that losing a limb is a big deal emotionally and many will not want to stand out. However as someone who has been interested in robotics since I was 11 years old my plan has always been that if I lose a limb I will build my own replacement. That gives me a lot of clarity on how I would proceed after the initial grieving and acceptance period.
Mail.ru will be owned by the Russian consortium as well. This divestment is to split their startups and a couple EU based assets from their Russian ones.
I agree with your posts(s), but conda is different to pyenv, poetry and similar tools (rye, hatch etc.) in that unlike the others which only manage Python, it (tries) to manage your whole environment. Can the others manage R packages (because your using r2py or reticulate)? What about installing pandoc? Or latex?
I suspect we're going to continue in having churn in what people seem to be calling project/environment managers simply because there's a bunch of possible workflows (given the various possible deployment scenarios), and there's enough library support that starting your own is a weekend project (and then all the corner cases are discovered and you make a choice that works for some but not others and the cycle begins anew). conda seems to have dominated its niche (I haven't seen activepython nor enthought in years), but I suspect that part of the ecosystem is more naturally stable.
Glad there is better tooling, but in 5 years, when I'll need it, I'm pretty sure I won't know how to use it.
I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are.
The package format itself is quite complex, and you don't know if you must do something imperatively or decoratively, when to trigger it in the workflow of the install, if it makes sense to use debconf or not, how to use debconf with something else than bash, good practices, where to put things, to copy files, etc. And that's before you have to deal with dependencies.
Then you have to repeat that for rpm.
No wonder people are attracted to flatpak and snap.
Creating a installer for mac, windows and linux is a hell of a work. Not to mention making sure it compiles and run on all those platforms.
Maybe you want a non deb specific packager. cpack (cmake packager) can generate Windows, OSX, DEB, RPM and simple archives. There is also fpm that doesn't support Windows, but supports plenty of packet managers. And possibly many others.
AppImage, FlatPak and Snap may actually be worse in that regard, because they are like other distros you have to take into account. So now, you may have to do all of them: deb, rpm, flatpak, snap, appimage, tgz, whatever that's on Windows and OSX, maybe a Docker container too, app stores and mobile stuff, and upload to some npm, maven, crate.io,... It makes generic package manager even more important.
The dh tools have a lot of magic to them. Arguably it works rather well, but figuring out how exactly to build a package correctly is difficult. The documentation is pretty bad, so if you want to do anything slightly different than the standard, your going spelunking in the debian directory of existing packages.
Debian could fix a lot of the troubles with the existing Debian Helper tools by improving the documentation.
> I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are.
After doing the first one, I was able to build binary, Debian packages in 5 minutes tops, while chatting with a friend during the process, too.
flatpak and snap are designed to solve different problems than OS native packaging paradigms.
Also, .deb and .rpm are much more capable and sophisticated than they look on the surface. Lastly, extracting a source and binary Debian package provides great documentation in itself.
Lastly, use lintian. That thing is a godsend (and does binary static analysis, too!).
For me rpm was relatively easy to grasp, it's basically a shell script and each section has a specific job (building, preparing, copying files etc.)
No matter how much I tried I could never grasp deb packaging. The documentation is very sparse and the debhelper commands seem like magic. I couldn't find out what all the different files like .dirs or .install did, so I just gave up.
I find RPM specs to be pretty frustrating. Easy cases like packaging GNU Hello is fine, but things get out of control really fast once you fall off the happy path. RPM specs are based simple text substitution. It lacks the flexibility to make adjustments to the build, the power to build good abstractions, and comes with all the same drawbacks of the C preprocessor. On top of that, documentation is lacking for basic macros, language ecosystem support is spotty and scattered across various obscure projects, and SCL packaging is a complete nightmare. The whole design seems dated compared to other solutions.
At that point, why even use package managers? That approach won't benefit from existing packaging infrastructure at all. Might as well distribute binaries in tarballs instead for simplicity.
The easiest package format I've ever came across was the tgz format from Slackware. From what I remember, you just build and install your software in a fake root then tar gzip it up.
This is because it doesn't do very much. Arch Linux's PKGBUILD and Alpine's APKBUILD are an excellent improvement on that, still very simple to use and learn. In most cases the source package consists of a single shell script (unlike Debian's splintered hell) where you have to define half a dozen fields and a couple of functions (build && install).
I basically have to relearn Debian packaging from scratch every time I have to do that, but learn Alpine and/or Arch once and you're all set.
It's the same process for all package builders: install build-time dependencies, unpack source archive with a program, configure it, build it, install it to a fake root, validate it, archive it to the package, sign it, then publish it to a repository, update repository index.
https://nixos.org/download#download-nix <--- I'm bookmarking this cause I keep forgetting that Nix can run atop other systems. I have no excuse to not give it a try
Binary deb packages are extremely simple. It's just a cpio archive with a couple of tarballs & almost every system integration is implicit. Very easy to build by hand.
Last time I shipped a debian package to clients we just had the build system spit out a ready made binary .deb. Much, much easier than faffing about with dhbuild etc.
My work workflow use `dpkg-deb`: I just create a "build/DEBIAN" directory, populate it with the control file and any post/pre scripts I need, put everything else in the "build" directory where it goes on the end filesystem and then do "dpkg-deb build ." I put all this into a script and do "fakeroot <SCRIPTNAME>".
I usually start with the `dh_make` generated skeleton and incrementally add overrides as I iterate with `gbp buildpackage`. It's not pretty, but it's what I know.
So it's not going to work, because they would not need it if people could gone without phone, and people who can't won't stio just because a bunch of other people will tell them it's better.
Social pressure doesn't work with addicts. Espacially if said addict are to a tool that also makes some tasks 10 times faster.