Slashdot Mirror
Oracle Fiddles With Major Database Release Cycle Numbers (theregister.co.uk)
An anonymous reader shares a report: Big Red has changed its database release cycle, scrapping names that see decimal points and numbers added on for an indeterminate amount of time, instead plumping for annual releases numbered by the year. So what would have been Oracle Database 12.2.0.2 will now be Oracle Database 18; 12.2.0.3 will come out a year later, and be Oracle Database 19. The approach puts Oracle only about 20 years behind Microsoft in adopting a year-based naming convention (Microsoft still uses years to number Windows Server, even though it stopped for desktop versions when it released XP). [...] Well, Big Red will surely be using the revamp as a way to boost sales of database licences -- a crucial part of its business -- which have been in decline for two years running. In fiscal 2016, Oracle reported a 12 per cent drop in annual sales of new software licences, and its most recent results for fiscal 2017 revealed a further 5 per cent drop. And, for all that Oracle has shouted about its cloudy success of late, it isn't yet a major money-maker for the biz. New software license sales make up a quarter of overall revenue, while support for that software makes up a further 45 per cent. In part, the new numbering will be a handy marketing ploy. Rather than playing with the decimal points, a release with a new whole number could be an attempt to give the impression of agility in the face of younger, fresher competitors. Meanwhile, fewer patches and releases on each system also allows Oracle to know more quickly, and more accurately, what security features each customer has. The annual numbering system is also a very simple way of telling you your system is old.
For quite a while minor point releases have had major API and behavior changes.
Technical matters aside, their auditors swarm into a company like Yakuza thugs making up fallacious reasons why the customer must pay more money or must use Oracle hardware. One of their lies is for virtualized customers, saying that every connected physical system where Oracle *might* run must be paid for as if the product really was running there. Of course, with careful legal work taking many months there nonsense can be refuted, and they'll leave....but that's after a large amount of man-hours of effort expended.
You've been warned. If you use their products, migrate. If you are considering using their products, don't.
If Oracle products werent dick infused with balls, their sales would be up. SAP is a close second.
Oracle Fiddles With Major Database Release Cycle Numbers
Does Rome burn.
The approach puts Oracle only about 20 years behind Microsoft...
So, in real-world terms, that's what? Two or three centuries ahead of Microsoft?
When Sun Microsystems was circling the drain, the CEO - MyLittlePony - figured monthly reorganizations could be used to hide layoffs.
Playing games with version numbers in the face of declining sales might have been the first symptom of MyLittlePony disease at Sun, as Solaris 2.5 went to Solaris 8, which was really Solaris 2.8, just like Solaris 11 is really Solaris 2.11.
>> What did I just read???!!!?
The ravings of a man who just went through an Oracle license audit.
-- which have been in decline for two years running
(snarky)Couldn't happen to a nicer company.(/snarky)
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
Surely the semicolon in the name won't cause any scripting problems.
Friends don't let friends use Oracle.
That is all.
It seems to me that his is a much more important issue than fiddling with release numbering.
So what does Oracle think? If someone cuts off his penis does that make him a woman for tax purposes? Also, in database design, should there be a field for noting if someone is really a woman or is just a johnny-come-lately to womanhood?
All database gurus please chime in . TIA!
Oracle started to confuse matters when they stopped going by the version number and started calling things 8i and 9i R2 and cloud and every other odd name they use.. 9i was 9.0, and 9i R2 was 9.2. Where did 9.1 go? Long ago, we deployed Oracle Reports for a customer. It ran on the 8i application server which was version 8.1, but was called Reports 6i. The reports function ran internally under an Oracle 8.0 home. I would prefer an overarching name, like Oracle Database 2018, and just use the version numbers to identify the actual versions of the components.
Then a release gets delayed into the next year, the release after that is delayed more, and then it becomes a joke. Company goes back to arbitrary numbers or names.
I eat only the real part of complex carbohydrates.
The headline should be "Oracle does something that you probably don't care about and does not affect you". I couldn't give less of a flying fuck how Oracle has decided to version its overpriced, bloated flagship product that funds Larrys yachts/islands. Yeah there are possibly a handful of Oracle DBAs reading this, they probably don't give a fuck either while they rake in their overinflated salaries. I hope Oracle dies.
Microsoft Windows initially adopted a pretty sane version numbering scheme. Everything was fine up to Windows 3.11, then suddenly we were at Windows 95, followed by Windows 98, a bewildering Windows 98 SE (Second Edition), Windows Millennium Edition (designed to conflict with Windows 2000, its NT cousin?).
What a mess! What was so great about 1995?
But under the hood, the major version numbers were still ticking over. Windows 95/98/Me = Version 4, Windows XP = Version 5, Windows Vista = Version 6, and then back to numbers again with Windows 7, and the list is soon to supplemented by Windows 8. But wait! Under the covers Windows 7 is actually Windows version 6.1. That makes no sense. I mean it really doesnâ(TM)t. Apparently the reason for this is to allow software that checks for compatibility to run correctly. Specifically, software written to run in Vista will run in Windows 7. This is stupid. Windows 8 is version 6.2! Windows 9 was skipped altogether because it would interfere with version checks that already looked for Windows 95 and Windows 98.
I don't know what Windows 10 is under the hood.
My UID is prime!
Many fewer people would end up reading it if you didn't reply to it with your +2 score.
Mod parent down.
Disclaimer: Oracle employee here, and I know Oracle isn't loved much here. But seriously - how is a comparison to a Microsoft versioning scheme even relevant? All products manage their own version numbers in their own way - that is not relevant to technical capability (or lack of, depending on your point of view). That summary is just a load of bias coming through.
Why the fuck does anyone buy anything from this shill of a company that is a really an attempt at corporate extortion?
The problem with whole number versioning schemes is that there's a fair amount of information lost. With the dotted schemes, you can tell if a new version is bug fixes, minor improvements, feature changes, etc. With a whole number scheme, all you know is the order in which versions are released.
But, as much as I dislike whole number versioning, I'll take them over using code names any day of the week.
I was an Oracle user for 25 years, took my first course on Oracle 6 in 1991. That was the introduction of it into my employer (City of Calgary) which was locked in IBM mainframery at the time; they had to accept Oracle as needed for GIS mapping, the ESRI and other GIS products all practically demanded Oracle.
Now, I was not up at the sysadmin end, where Oracle's tools for moving whole databases about, and spreading them across disks and servers and all that, are greatly appreciated. But just as a user, all the needs I had for a GIS database had been replicated in Free Software by the time I retired.
I think Postgres stacks up fairly well against Oracle, even for the sysadmins fussing over partitions and multiple servers, these days; but for my needs, now considered humble, a mere 10GB database of every pipe, every house, every lot and street, every bit of water infrastructure in a large city and all the work-orders done on those pipes in 10 years - was handled by PostGIS (Postgres with a GIS plug-in) with ease. On a laptop. I started doing real work on my PostGIS copy (and no, transfer from Oracle to Postgres was not remotely difficult) because I had more control over it, was the DBA. Convenient sometimes.
I guess some Oracle admins will always have a situation where they can say "the free software alternatives just don't let me manage my petabytes easily for 365x24 service", fair enough.
But so many work needs can be handled well by a reliable database product that can manage a mere few hundred gigabytes quickly and well, that I think if everybody who *could* switch to Postgres *did* switch to Postgres, Oracle would be trying to fund itself on a small fraction of their current customer base, though they would all be huge customers.
I wouldn't have written that in 2012 when I first looked at Postgres, but their developments since 8.5 have been especially impressive. I recall a debate in their committees a few years back where they worried not enough developers were handling the routine bug-fixes and minor upgrades with each version: too many people were excitedly putting in major new features like 'big database support' and UPSERT (9.5), "parallel query and synchronous replication" (9.6) and so on, to take care of basics. They've had a very impressive five years. As to the predictions for Postgres 10, I can't even understand them: http://rhaas.blogspot.ca/2017/... ... but they are apparently awesome from the fan reviews.
I tried to get IT at work to have a look at Postgres, but it was a non-starter: our PeopleSoft application is married to Oracle and there's no way they'd have two DB products. Indeed, Oracle may be safe for decades yet unless somebody like EnterpriseDB comes up with a really popular Oracle-to-PG migration for both SAP and PeopleSoft. Those things could not be removed from most large corporations with a nuclear-powered crowbar, so they're Oracle's best lock-in partners right now.
However, in this case I think they should just keep going. Just because even the more exceedingly uncool kids are doing it doesn't mean you should.
Yes Francis, the world has gone crazy.
I've also worked GIS and Oracle (not always together) for almost 20 years now. I wouldn't disagree with your assessment of Postgres/PostGIS. However it is a somewhat "new" technology. I see new innovation in that direction. However at the same time we have a ton of legacy applications in Oracle too expensive to replace, the lock-in with Oracle makes moving more difficult, and the amount of inertia involved with that load keeps pulling in that direction. That said, most of the newer releases (The oldest I've worked with was 7 something I believe), while they might offer some new features or functions are more less lost on the legacy application other than that they maintain a somewhat modern compatibility and support. In fact in all the upgrade cycles we've gone though only the change from 10 to 11 caused any problems. That was when they decided to change how Oracle handled upper and lower case values, which played holy hell with a bunch of legacy applications search functions that had be coded a bit more loosely (i.e. they didn't consider upper/lower at the time, whereas some others more robustly manually constrained it to one or the other within code). It was confusing for a time, until it was also noticed that number searches worked just fine. Anyway I see some movement from Oracle, but it is going to be a slow slog, and really won't happen until all those legacy applications start to really fall apart. Even then going to something that is open source is a tough call for large organizations, particularly when taking into consideration support and training and the like (and what consultants and whatnot are out there and available).
We run a postgresql 9.3 database which grows a couple of GB per day, is currently about 1.2TB large, on the standard distribution settings. Only recently we started running into performance issues because we didn't bother to tune the configuration to make optimal use of the 64GB of RAM the VM has. (e.g. shared_buffers is still at 128MB instead of something like 16GB or more).
More marketing gimmicks, exactly what Oracle needs to turn its slimy reputation around. Brilliant!
Table-ized A.I.