Is this any better than just doing Hotspot with wifi bridge? I just have my hotspot on my pixel for my devices to connect to. Pixel itself is connected to whatever
"public wifi" is there.
Your hotspot just makes the untrusted hotel wifi available via your phone wifi. The networks between your computer and your target services can still inspect and alter your data. Tailscale, or more specifically the Wireshark underneat, sets up an encrypted tunnel so those "untrusted" intermediate networks can't do that.
Yes, but it wont work for sharing mobile internet because VPN doee not apply to tethering unless you have root. On Android there is also WiFi direct, but it's not very reliable and require proxy / not work for everything.
Unfortunately, iPhone can't bridge wifi networks, which makes travel routers particularly useful if you have an iphone, and a laptop, and are staying at a hotel with wifi.
It's my understanding that personal hotspot can only utilize the cellular connection for the internet side since the wifi connection is being used to connect clientside. If one is hoping to use hotel wifi rather than their cellular plan data, Apple's solution won't work.
Yes, it has actually worked starting with the Pixel 3.
It's called Dual-Band Simultaneous or "STA+AP" (Station + Access Point) concurrency that can bridge an existing wifi connection to an access point to other devices via a hotspot.
In my experience hotels throttle wifi connection per device (IP/Mac address or whatever) and so you'd be better off using something that can use the wired connection in your room (which is usually unthrottled or has higher bandwidth) and be an AP for your personal devices.
If you don't have a wired connection then this wouldn't be any better, except for any connectivity features it might offer (probably some vpn capability).
I have a gl-inet device and it does pretty much all I need whenever I travel.
Hotels in Las Vegas typically charge around $15/day per connected device. Want to download a new book on your Kobo and play Diablo for a few minutes? That’ll be $30, please!
I can second 3blue1brown as intro, but anything practical needs practise. Get your local 12th grade or undergrad math book which has problems to solve will bring more focus and faster learning. Have a list of problems to solve in your head while learning theory has been faster for me than just learning theory.
Browser handling is way more personal than any other piece of software. It need not be open source licensed but being able to compile and install it from source the exact binary (minus signing) is a huge plus is today's world. Otherwise is "not" doing much from chrome, brave, firefox etc of today. Open source would be cherry on top.
Trust of Kagi search is already there w.r.t both the tool and the company but it is not transferable to Trust to the Orion Browser.
AGI might be possible with more Param+Data scaling for LLM. It is not completely within the realm of impossible given that there is no proof yet of "limits" of LLM. Current limitation is definitely on the hardware side.
This is what I'm talking about. The correct tech would enable the strands of information in a vector to "see" each other and "talk" to each other without any intervention. This isn't the same as using a shovel to bash someone's head in. AGI would need tech that finds a previously undocumented solution to a problem by relating many things together, making a hypothesis, testing it, proving it, then acting on it. LLM tech will never do this. Something else might. Maybe someone will invent Asimov's positronic brain.
I think _maybe_ quantum computing might be the tech that moves AGI closer. But I'm 99.9999% certain it won't be LLM tech. (Even I can't seriously say 100% for most things, though I am 100% certain a monkey will not fly out of my butt today)
Quantum compute would definite make a leap to moving closer to AGI. Calculating probability vector is very natural for quantum computer or more precisely any analog compute system would do. qubits==size(vocab) with some acceptable precision would work i believe.
The processing capability of today’s CPU’s and GPU’s is insane. From handheld devices to data centers, the capability to manipulate absurd amounts of data in fractions of a second is everywhere.
Maybe it is the algorithms. But just by doing a op for an 10^25 param llm is definitely not feasible on todays hardware. Emergent properties does happen at high density. Emergent properties might even look as AGI.
The condescension is coming from "We want to make sure we trully understand what you're struggling with." which is completely dismissing the points they made in the post. Basics "surely there is more to it than just what is in the post". A better response would have responded with actions/talking points to the items listed in the post. Then asking for a call for further clarification of the respondents point.
one thing which causes problem with git for me is collaborative work without using "git server". This usually comes up at homelab situation with no access a "git server" or ssh server. One thing with jj is i can use existing sharing mechanism like dropbox, google drive or if nothing else just copying jj folder (granted all of those are bad idea w.r.t vcs but still).
I don’t understand this critique. You can copy a .git folder around just fine. You can expose a “server” by giving friends ssh keys that can only access the git stuff. In fact for a long time that’s how git “was done” at various corps.
That said, I haven't tried this lately, maybe it's gotten more robust over time. But historically, even a bare repo on something like Dropbox has issues.
Sure, but this seams to be more of an issue with Dropbox, not with Git, when I run a database on Dropbox, the same problems occur. I wouldn't trust these to even preserve file attributes correctly, so I would put things into a tarball, before uploading (optionally also encrypting).
Sure, you could view it as Drobox's problem, but the core of it is that git relies on things that Dropbox doesn't support, while jj does not. And so it's usable more safely in more contexts.
No, it avoids doing that (see the link someone shared above). Git actually also rarely overwrites files. The only case I'm aware of are refs, so I think it could happen that a if you modify a branch on two machines and then sync via Dropbox/rsync, one of those changes could get lost.
Ah, you mean to share the repo you are issuing git commands to directly. Yeah I would expect this to cause problems. Surprising to hear that JJ supports this.
This wasn't what I was talking about, I meant that you should create a bare repo and push to it, not that you work directly in a directory in Dropbox.
Git server is just a directory. It may or may not have actual content files in it (aka bare). In fact, any git clone of any repository is also a server on its own (and clients can have multiple "remote"s to pull from).
My go-to solution for this problem is a git init --bare --shared=group repository in a shared mountable drive. Then you can declare that repo origin, and tada, git push/pull works.
It calls "git" to "init"ialize a repository, which we don't need a working tree for ("bare") and that it's going to be "shared" with members of the "group".
EV Certs used to do exactly that for me, that is until browser stopped make the visuals of it special. Don't think it would be even viable today given the short expiry (which is a good thing) of TLS certs necessary for browser
You can still do all the checks you need, they're right there in the connection properties. This website is OV-certified (not EV) to PayPal, Inc. in San Jose by DigiCert Inc.
I don't see why EV wouldn't be viable. ACME can work with any certificate. A certificate authority can just sign new certificates every week at the request of an authenticated ACME client. The biggest issue with this workflow is the CA's billing flow optimised for the "pay once, hand over a file once" workflow.
I talked about introducing a notability criteria in the US, and other jurisdictions where duplicate registrations are possible. The Chrome people weren't interested.
reply