Is an SSH jump server a VPN (or forwarding a port from another machine at VPN)? I'd suggest neither are because it's connection-based rather than setting up a network (with routing etc). Absent a network, it's a proxy (which can be used like some deployments of a VPN).
I see your point, but I think that might label many uses of wireguard in tailscale "not a VPN" because they use imaginary network devices that only exist inside the tailscale process. Saying that would feel very wrong. On the other hand if process internals can be the deciding factor, then optimizing the code one way or the other could change whether a system is "VPN" or "not a VPN" even though it looks exactly the same from the outside. That doesn't feel great either.
And do we even know if Opera uses internal network addresses for its "VPN"?
I think I'm willing to say that routing all internet traffic from a program through a tunnel can be called either a VPN or a proxy.
I'm not up-to-date with the internals of tailscale, but my impression was they run additional services on top of the actual VPN (that is their "value-add" to wireguard), some of which are actual proxies, which hence blur that line in the minds of users (along with some so-called "VPN" providers who are just providing proxies).
In the modes I'm talking about, there's a real wireguard VPN that your local tailscale process is participating in. But instead of attaching it to a TAP device, there's a whole virtual networking stack inside the tailscale process.
You could treat it like running a normal VPN app inside a virtual machine. Surely that's still be a VPN, or the distinction gets weird. But if we do agree it's a VPN, a couple examples based on this one will force the distinction to get weird anyway. The line of VPN or not is surprisingly blurry.
Really none of these VPNs are VPNs either since they don't establish a virtual private network. They are just tunnels for your internet access. Tailscale is actual VPN software. It simulates a private network.
I've a bachelors of science (first) in computer science, and currently doing a dissertation for a master's in cyber security, on route for a first but that might change depending on the mark for this dissertation.
My experience with the bachelors was that despite my project being derailed by the bullshit around formatting the document, doing "research" by searching the library for peer reviewed papers that backed up my claims, etc, etc; I got a excellent mark. In short I set out to make something and due to the academic processes failed in making anything, but because I was able to critically reflect on it, I got a good mark. Waste of time, unless you were just are a good mark.
For my masters I know the project doesn't matter, I'm concentrating on the academic nonsense because that's where the marks are.
The work you were given in your undergraduate and master’s was not research, it was homework. The task was critical reflection, which is repeatable and achievable for students; whereas research is expensive, one off, and generally out of reach for undergrads, and requires intensive oversight by an experienced researcher.
The waste of time would be for a professor to train you up to be a researcher before you’ve proven you are ready, hence the homework assignments.
If that's the case then and researching is way above masters level then how is it you get on a PhD? Genuine question. If everything I've done to date is a pale imitation of the real thing how can I make a fair assessment as to whether I want to pursue a PhD?
You don’t really, and why a lot of people become researchers only to discover they hate it. But that’s true with all things.
I think the way to know if you want to be a researcher is more along the lines of: do you like finding the answers to questions no k e has thought to ask let alone answered? If so then it doesn’t really matter the training you’ve or the amount t of the field you’ve experienced, you can focus on that bit as your guiding force.
No, it's not about whether masters or PhD, it's whether you did something new (the novelty aspect). It sounds to me that you did a coursework masters of some kind, which gave some basic literature analysis projects. This is like the first month of any research project, and is so you understand the context of the project. The actual work is doing the novel thing, and dealing with the repeated failures.
My suggestion is do a summer research project, and see if you enjoy it. If no-one will take you on, reflect on why that is (and to me that's a strong reason not to do it).
Where do you think they get the training data from ;) Galaxy Zoo has been used to train ML models for at least a decade, it's a standard dataset for intro to ML courses.
It's worth noting that while splitting the PKI hierarchies is a good thing, the CABF does provide rules S/MIME (email signing) and Code Signing. Also, "WebPKI" never actually appears in the BR documents from what I can see, nor do they require the use of HTTP (hence why you can use these for SMTP).
The issue is corporate-managed systems are universally bad (with the endless cycle of something new coming in and being ruined), and so while in theory email can be great, the workflows to make it work inherently conflict with the corporate setup...
How do you know you're more productive? Humans are excellent at fooling themselves, and absent a metric (or multiple metrics) by which you can measure your productivity, you can't be sure you're actually being more productive.
I don't know if it's made me more productive but I do know that for the past ten years I've been thinking about making an intermediate mode GUI toolkit for MPV user scripts, rendered with ASS subtitles and with a full suite of composable widgets, but for ten years I kept putting it off because it seemed like it would be a big quagmire of difficult to diagnose rendering errors (based off far more modest forays into making one-off GUIs in this way.) And I know that yesterday I decided to explain my idea to claude and now it just fucking works after just a few hours of easy casual back and forth.
I don't know man, could just be in my head. I better defer judgement, put aside all my own opinions about what happened and let some researchers with god knows what axe to grind make that decision for me.
I'm very very sure. Based on my last 15 years of coding experience I can assist fairly accurate how much a task takes. With AI I can finish the task 2x-4x faster (this includes testing, edge case handling etc).
There's a difference between dead (i.e. "unmaintained") and low activity ("not under active development"). From what I can see PyPy is in the latter category (and being in that category does not mean it's going to die soon), so choosing to claim it is unmaintained is notable.
I'd genuinely be curious what fraction of those changes actually requires porting to other Python implementations. The free-threading changes are inherently interpreter specific, so we can ignore those. A significant change in Python 3.12 is dropping "dead batteries", so that can be ignored as well. From what I can see, the main language changes are typing-based (so could have parser implications), and the subinterpreter support being exposed at the Python level (I don't know whether that makes sense for PyPy either). I think this hints that while certain area of Python are undergoing larger changes (e.g. typing, free-threading), there is no obvious missing piece that might drive someone to contribute to PyPy.
Also, looking at the alternate (full) interpreters that have been around a while, PyPy is much more active than either Jython or IronPython. Rust-python seems more active than PyPy, but it's not clear how complete it is (and has going through similar periods of low activity).
Would I personally use PyPy? I'm not planning to, but given how uv is positioning itself, this gives me vibes of youtube stating it will drop IE 6 at some unspecified time in order to kill IE 6 (see https://benjamintseng.com/2024/02/the-ie6-youtube-conspiracy...).
The problem is the million small paper cuts. The stdlib changes are not all in pure python, many have implications for compiled modules like _ssl. The interpreter changes, especially compatibility with small interpreter changes that are reflected in the dis module, also require work to figure out
I don't know about that. For me, f-strings were the last great quality-of-life improvement that I wouldn't want to live without, and those landed in Python 3.6. Everything after that has not really made much of a difference to me.
This reads like you think that "major" version bumps should ony happen when things make a big difference to you personally. At least that's where you land when you follow the logic of your statement. I think you may overrate the importance of your particular use case, and misunderstand what GP meant by "major".
The gist of what GP meant is that Python does not exactly follow SemVer in their numbering scheme, and they treat the middle number more like what would warrant a major (left-most) number increase in SemVer. For example, things will get deprecated and dropped from the standard library, which is a backwards-incompatible change. Middle number changes is also when new features are released, and they get their own "what's new" pages. So on the whole, these middle-number changes feel like "major" releases.
That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.
> A is the major version number – it is only incremented for really major changes in the language.
> B is the minor version number – it is incremented for less earth-shattering changes.
> C is the micro version number – it is incremented for each bugfix release.
> That being said, the Python docs themselves [0] call the left-most number the "major" one, so GP is not technically correct, while I'd say they're right for practical, but easier to misunderstand, purposes.
That's ultimately the point I was trying to make; my inner pedant can't help but feel the need to push back on people using versioning terminology inconsistently, but in practice I don't think it really made much of a difference in this case.
Oh, you are right, I forgot that "major version" is a technical term and incorrectly read it as "For Python, 0.1 increases make a big difference". My bad!
If you want your code to run, you need a python interpreter that supports the newest of your dependencies. You may not use features that came after 3.6 (though you obviously do), but even if just one dependency or sub-depdendency used a python 3.10 specific feature you now need interpreter at least this new.
That is true, and it is also a huge pet peeve of mine. If more library maintainers showed some restraint it using the newest and hottest features, we'd have much less update churn. But on the other hand, this is what keeps half of us employed, so maybe we should keep at it after all.
They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.
Or at runtime, you can import things from the standard library which require a minimum 3.x. - .x releases frequently if not always add things, or even change an existing API.
> They are de facto semantic major versions - think of recent-ish additions like f-strings and match-case (3.7 and 3.11, I think), you'd get a syntax error in an older parser. PyPy targeting 3.9 for example would would support f-strings but not match-case.
Are you saying that you'd get an error using the new feature on an old version, or that code that used to parse on old versions would not longer work on the newer version? The former is pretty much a textbook example of a minor version update in "traditional" semver; a single new API function is enough to potentially make new code not work on old versions, since any calls to that function will not work on versions predating it. The latter is what would constitute a "breaking change" in semver; old code that used to work can't be made to no longer work without a major version bump.
I say "traditional" semver because in practice it seems like there are fairly few cases in which people actually seem to fully agree on what semver means. I've always found the "official" definition[1] to be extremely clear, but from what I can tell most people don't really adhere to it and have their own personal ideas about what it means. I've proposed things in projects that are fully within both the letter and spirit of semver quite a few times over the years only for people to object on the basis that it "isn't semver" because they hadn't fully read through the description before. Typically I'll mention that what I'm suggesting is something that semver allows and bring up the page and show them the clause that specifically allows what I'm saying but clarify that I recognize we still might not want to do it for other reasons, and the other person will end up preferring to stick with their initial instinct independent of what semver actually says. This is totally fine, as semver is just one of many versioning scheme and not some universal optimum, but my point is that it's probably more confusing for people to use the same term to describe fairly inconsistent things.
True - I don't think I really had my head screwed on there. It just 'feels different' because it's language level, the actual syntax, I suppose, but no - you're right.
It’s been a lot longer than that. There was a reasonable sized effort to provide binaries via conda-forge but the users never came. That said, the PyPy devs were always a pleasure to work with.
The problem is that it is lagging behind enough that it is falling out of the support window for a lot of libraries.
Imagine someone releases RustPy tomorrow, which supports Python 2.7. Is it maintained? Technically, yes - it is just lagging behind a few releases. Should tooling give a big fat warning about it being essentially unusable if you try to use it with the 2026 Python ecosystem? Also yes.
3.11 still has 2 years of active security patches, and has most of the modern python ecosystem on tap. That is a whole different ballgame than stuff stuck in the pre-split 2.x world
It is somehow less funny today but in the 90's we would say "is there something wrong with your hands?"
A truly funny story: I wrote an rss aggregator and one day I discover some feeds had died without me noticing it. I looked at the feed, it was gone, I look at my aggregate and the headlines were all there?!?!
Since I gather a lot of feeds I couldn't help but noticed that a very large amount isn't wellformed. For example, in xml attributes the & (in urls) is suppose to be &, if you do that however many aggregators won't be able to parse it.
Every other month I wrote little bits of code to address the most annoying issues.
1) if I cant find a <link> or <guide> etc I eventually just gather <a>'s and take the href.
2) if I really cant find a title for the item I had it fail back on whatever is in the <a> since I was gathering those anyway.
3) if I cant even find an <item> I just look for the things that are suppose to go in the <item>
4) if I cant find a proper time stamp ill try parse one out of the url
5) if the urls are relative path complete them.
What was actually going on: The feed was gone, it redirected to the home page. In an attempt to parse the "xml" it eventually resorted to gathering the url and title from the <a>'s and build valid time stamps from the urls.
