5 ms·

I am saying this as a lifelong supporter and user of open source software: issues like this are why governments and enterprises still run on Oracle and SQL Serv

by crmd 1y ago

I am saying this as a lifelong supporter and user of open source software: issues like this are why governments and enterprises still run on Oracle and SQL Server. The author was able to rollback his changes, but in some industries an unplanned enterprise-wide data unavailability event means the end of your career at that firm, if you don’t have a CYA email from the vendor confirming you were good to go. That CYA email, and the throat to choke, is why Oracle does 7 and 8 figure licensing deals with enterprises selling inferior software solutions versus open source options. It seems that Linux, through Linus’ leadership, has been able to solve this risk issue and fully displace commercial UNIX operating systems. I hope many other projects up and down the stack can have the same success.

duncanfwalker 1y ago
At the start of your comment I thought the 'issues like this' were going to be the 4 year discussions about what is and isn't core.
- crmd 1y ago
  So did I :-) but I think the concepts are related: Linus’ ability to shift into autocratic leadership mode when necessary seems to prevent issues like the 4 year indecisiveness on v2/core from compromising product quality to the point where Linux is trusted in a way that rivals commercial software.
  - duncanfwalker 1y ago
    +1 you're paying for the governance as much as you're paying for the code.
    - crmd 1y ago
      Well said, thank you
moelf 1y ago
and why CERN rocking their own file format, again in, 2025, https://cds.cern.ch/record/2923186 https://cds.cern.ch/record/2923186
- 3eb7988a1663 1y ago
  To be fair, CERNs needs do seem fairly niche. Petabyte numeric datasets with all sorts of access patterns from researchers. All of which they want to maintain compatible software forever.
  - moelf 1y ago
    yeah except this new RNTuple thing is really really similar to Apache Arrow
forinti 1y ago
People keep using Oracle because they have a ton of code and migration would be too costly. Oracle is not imune to software issues. In fact, this year I lost two weekends because of a buggy upgrade on the cloud that left my production cluster in a failed state.
- chrismustcode 1y ago
  A lot of these have business logic literally in the database built up over years. It’s a mammoth task for them to migrate
  - reactordev 1y ago
    Oracle Consulting gladly built it all as stored procs with a UI.
    - jtbaker 1y ago
      > built billed
      - reactordev 1y ago
        annually
- taneq 1y ago
  It’s not about being immune to software issues. It’s about having a vendor to cop the blame if something goes wrong.
  - forinti 1y ago
    It doesn't do me any good. All I can get from Oracle is the possibility of opening a support ticket and then having to send them tons of log files. If I use max severity, they expect me to be available 24/7, any other severity means they'll take weeks to look at it. Most times I prefer to wade through the knowledge base until I find a solution.
1a527dd5 1y ago
Polite disagree; governments and enterprises remain on Oracle / SQL Server because it is borderline sisphean. It can be done (we are doing it) but it requires a team who are doing it non-stop. It's horrible work.
atombender 1y ago
Sorry, I think you misunderstood this article. When the author is talking about rolling back his changes, it's not referring to a database, but a version of his library. If someone tried used his new version, I assume the only thing that would have gone wrong is that their code wouldn't work because Pandas didn't support the format. This article is about how a new version of the Parquet format hasn't been widely adopted, and so now the Parquer community is in a split state where different forces are pulling the direction of the format in two directions, and this happens to be caused by two different areas of focus that don't need to be tightly coupled together. I don't see how the problems the article discusses relate to the reliability of software.
- kristianp 1y ago
  I think the gp understood the article. They are talking about the people's software breaking when the author switched his software to v2 of Parquet.
  - atombender 1y ago
    This is a small Java library used for data science/engineering purposes, and the upgrade would stop it from being able to read Parquet 2 files. If that causes an "unplanned enterprise-wide data unavailability event", that is the fault of the application developer that chose to upgrade their dependencies, not the library author. Furthermore, you could say the same things about any third-party library in the world, so drawing the connection to big vendors like Oracle is a non sequitur at best.
rbanffy 1y ago
> The author was able to rollback his changes, but in some industries an unplanned enterprise-wide data unavailability event means the end of your career at that firm If a (major) software update cause you an outage, you shouldn’t blame the software, but insufficient testing and validation. Large companies (I worked for many) are slow to adopt new technologies precisely because they are extremely cautious and want to make sure everything was properly tested before they roll it out. That’s also why they still use Oracle and SQL Server (and HP-UX, and IBMi) - these products are working and have been working for generations of employees. The grass needs to be significantly greener for them to consider the move to the other side of their fence.

by crmd 1y ago

duncanfwalker 1y ago

At the start of your comment I thought the 'issues like this' were going to be the 4 year discussions about what is and isn't core.

crmd 1y ago
So did I :-) but I think the concepts are related: Linus’ ability to shift into autocratic leadership mode when necessary seems to prevent issues like the 4 year indecisiveness on v2/core from compromising product quality to the point where Linux is trusted in a way that rivals commercial software.
- duncanfwalker 1y ago
  +1 you're paying for the governance as much as you're paying for the code.
  - crmd 1y ago
    Well said, thank you

moelf 1y ago

and why CERN rocking their own file format, again in, 2025, https://cds.cern.ch/record/2923186 https://cds.cern.ch/record/2923186

3eb7988a1663 1y ago
To be fair, CERNs needs do seem fairly niche. Petabyte numeric datasets with all sorts of access patterns from researchers. All of which they want to maintain compatible software forever.
- moelf 1y ago
  yeah except this new RNTuple thing is really really similar to Apache Arrow

forinti 1y ago

People keep using Oracle because they have a ton of code and migration would be too costly. Oracle is not imune to software issues. In fact, this year I lost two weekends because of a buggy upgrade on the cloud that left my production cluster in a failed state.

chrismustcode 1y ago
A lot of these have business logic literally in the database built up over years. It’s a mammoth task for them to migrate
- reactordev 1y ago
  Oracle Consulting gladly built it all as stored procs with a UI.
  - jtbaker 1y ago
    > built billed
    - reactordev 1y ago
      annually
taneq 1y ago
It’s not about being immune to software issues. It’s about having a vendor to cop the blame if something goes wrong.
- forinti 1y ago
  It doesn't do me any good. All I can get from Oracle is the possibility of opening a support ticket and then having to send them tons of log files. If I use max severity, they expect me to be available 24/7, any other severity means they'll take weeks to look at it. Most times I prefer to wade through the knowledge base until I find a solution.

1a527dd5 1y ago

Polite disagree; governments and enterprises remain on Oracle / SQL Server because it is borderline sisphean. It can be done (we are doing it) but it requires a team who are doing it non-stop. It's horrible work.

atombender 1y ago

Sorry, I think you misunderstood this article. When the author is talking about rolling back his changes, it's not referring to a database, but a version of his library. If someone tried used his new version, I assume the only thing that would have gone wrong is that their code wouldn't work because Pandas didn't support the format. This article is about how a new version of the Parquet format hasn't been widely adopted, and so now the Parquer community is in a split state where different forces are pulling the direction of the format in two directions, and this happens to be caused by two different areas of focus that don't need to be tightly coupled together. I don't see how the problems the article discusses relate to the reliability of software.

kristianp 1y ago
I think the gp understood the article. They are talking about the people's software breaking when the author switched his software to v2 of Parquet.
- atombender 1y ago
  This is a small Java library used for data science/engineering purposes, and the upgrade would stop it from being able to read Parquet 2 files. If that causes an "unplanned enterprise-wide data unavailability event", that is the fault of the application developer that chose to upgrade their dependencies, not the library author. Furthermore, you could say the same things about any third-party library in the world, so drawing the connection to big vendors like Oracle is a non sequitur at best.

rbanffy 1y ago

> The author was able to rollback his changes, but in some industries an unplanned enterprise-wide data unavailability event means the end of your career at that firm If a (major) software update cause you an outage, you shouldn’t blame the software, but insufficient testing and validation. Large companies (I worked for many) are slow to adopt new technologies precisely because they are extremely cautious and want to make sure everything was properly tested before they roll it out. That’s also why they still use Oracle and SQL Server (and HP-UX, and IBMi) - these products are working and have been working for generations of employees. The grass needs to be significantly greener for them to consider the move to the other side of their fence.