Trademarks don’t need to be applied for - a “common law trademark” is established through use. Much harder to protect than a “registered trademark” though, as you need to actively defend, rather than the mark simply being present in a registry.
Using this doesn't prevent you from using another email client to access the inbox too. It is true you don't get the same view to your data on all clients/platforms but then again this is usually true to a large extent always when using multiple generic email clients to access the same inbox.
It doesn't seem entirely fair to say it stems from "marketing". There were and still are plenty of fully functional applications that rely on the filesystem attributes and indexing on BeOS/Haiku.
I'm sure it is way more limited than some original failed vision but limiting scope doesn't have to be a bad thing and I think what they ended up with does live up to the hype in some ways. That said, it certainly also has some flaws like not even being able to efficiently use the index for the built-in file find dialog because of case insensitivity.
No - it was marketing. The older Filesystem was a full on database and would allow the user to do all kinds of weird and wonderful things with metadata. But the Filesystem interface in BeOS prior to PR1 (well, technically AA) made it almost a herculean feat to interface an external non native file system to the OS.
BFS was written in a way that complied to a file system API that could then support other non-BFS file systems being plugged in. But because it was written in more of a traditional file system way, the database features got massively cut down to just attributes and indexes with live queries. It was a trade off. The database hype built by the DR releases (mainly for BeBox, I think only one made it publicly to Mac) was maintained because the attributes sort of mimicked the bare minimum functionality needed to tick a marketing box. But BFS really doesn't do much more than some other file systems have since done.
The OFS was more like the SQLServer based WinFS that Longhorn was going to have.
Well, I probably haven't seen the marketing you're referring to if it all happened before even that prerelease but people have kept talking about the BFS features for decades now and the interest is certainly not all based on some early marketing.
Yes it is a trade off. Not sure what other file systems you are referring to but I'm not aware of any others that enable the kind of applications BeOS had using these features. Those are also a key part of it.
Exactly. These EOL dates aren't really helpful in a world where most people just use a handful of distros. WordPress keeps sending the same unhelpful message and I hate it.
Just the other day, a somewhat technical client of mine called me to ask if his PHP 7.0 installation has gaping security holes. I said no, you're using Ubuntu 16.04 LTS, you'll be fine until April 2021. If you force an upgrade now, you might run out of support even earlier.
My go-to version for production right now is PHP 7.2. I'm going to ignore all warnings about its EOL until 2028, when support for Ubuntu 18.04 runs out. Wait a sec, add another year for RHEL/CentOS 8 which is also going to support PHP 7.2 for the next 10 years. PHP 7.2 is going to outlive a whole bunch of future versions.
> My go-to version for production right now is PHP 7.2. I'm going to ignore all warnings about its EOL until 2028, when support for Ubuntu 18.04 runs out.
I'm not sure you can just hide behind the LTS assurance of the OS, they can't guarantee every single package in their repos will remain safe. Plenty of packages in Ubuntu LTS releases reach EoL far far before OS EoL.
True, but PHP tends to be looked after fairly well given its importance to the web ecosystem.
Ubuntu for example has a pretty good track record of backporting PHP security fixes. PHP 7.0 in Ubuntu 16.04 has been getting updates every few weeks despite the EOL last winter, and I remember observing the same with PHP 5.5 in 14.04 until the OS itself reached EOL earlier this year.
The fact that both Red Hat and Canonical are committed to supporting PHP 7.2 for the next decade probably means that there will be more eyes on that particular version, and more hands to patch it, for the foreseeable future. It's a nice coincidence for people who want a bit of stability now that PHP has begun to change rather quickly.
Ubuntu and CentOS are maintaining versions that upstream has already EOL'd, so there's no upstream to push patches to. Most other distros (hello, Fedora) have much shorter support cycles so they don't really need those patches, either. There might be some sharing between Ubuntu and Debian LTS.
The majority of patches still come from upstream. If a new vulnerability is found in PHP 7.1 or 7.2, chances are the same bug exists in 7.0. So the maintainers check if their versions are also vulnerable, and if so, backport the fixes. As time goes on and differences accumulate, patches from upstream will become less relevant. It looks like Red Hat largely gave up on maintaining PHP 5.3 in RHEL/CentOS 6 after about 7 years. We'll have to see how long they actually stand behind PHP in CentOS 7 and 8.
I mean 'guarantee' is a pretty strong word in the world of security. Better phrasing might be "is committed to backporting security fixes for the lifetime of the OS."
I am running CentOS 7 and that is still using 5.4. I am only running a forum, IRC and some other things and I don't really want to bother with third party packages.
For what it's worth I've been using PHP 5.6 via Software Collections (SCL) on my CentOS 7 system for a few years with zero problems. I think I will update to PHP 7.x soon (probably 7.2).
> There was this amusing incident not long ago, where the store's fraud prevention mechanisms were blocking users who bought five or six games quickly in a row.
That's funny, recently numerous users were also blocked from purchasing the Valve Index VR system on Steam because of fraud prevention mechanisms.
To their credit Valve did later offer an opportunity for people who ran into this to buy a kit in the first wave of shipments.
Thanks. Not sure where they got it from. The Anandtech article that is linked to there does contain some TFLOPS numbers but I think they came up with those numbers somehow based on the CUDA core count so could well not be accurate.
I guess it's just simply twice the number of Cuda cores times the operating frequency and so it's accurate as such but lots more goes into gaming performance of a GPU.
