If you think that AD on the cloud is a nightmare
Wait until you experience the on-premises version. It is exactly the same, only it is you who is applying and rolling back updates.
325 posts • joined 30 Jul 2014
mmmm... so HANA does not handle well tables of a type that 60% of customers have. That HANA is designed that way speaks volumes about how much SAP disregards its customers's needs.
On the rest of the points, I agree, no migration of such data volumes and complexity is ever going to be easy. What is unusual here is how your own product handicaps the migration by its very own features. It is usually a sign that migration is not a good idea in the first place.
So some years ago, you moved your ERP to a SAP application on the basis, among other supposed benefits, of having all your enterprise data consolidated in a single database. That would have make it much easier to mange and report. And of course, your ERP vendor should take care of future upgrades.
Now SAP is offering you an "upgrade" to a supposedly much more faster and efficient database platform (HANA). However, SAP is not automatically moving your data from the existing database to the new database. Also, you have what appears to be too much data for your new, remember, faster and more efficient platform, to digest.
So exactly what was the benefit of moving to SAP in the first place? Specially if you neither have an automated migration path to new versions nor the same database capacity and scalability in the new versions?
Is starting to sound like the "cloud is bad because I can do cheaper" folk. Listen: in your own little world things are simple, don't change frequently and the longer app you've had to deal with is about 10K lines of code. Outside of that world, type checking may not be perfect, but at least is one more barrier against bugs.
What I find incredible is how all these councils, hospitals, etc keep re-inventing the same wheel over and over again. Creating a new ERP implementation for a council should be as easy as: (1) find the council with a working ERP implementation that has the closest business processes and rules as your own (2) get that council source code and parametrization and isntall a fresh instance (3) change your instance to comply where your requirements are different (4) everyone wins: council gets a much quicker implementation and saves taxpayer money.
On second thought, I see two problems with this approach: if there is nobody yet at step (1) you don't have anything to start from and you are then not re-inventing but inventing. But there should be at least one, right? And yes, you could save a lot of money on external suppliers. Which is not good for external suppliers. So no, not everyone wins.
Each and every time I upgrade KDE I find it fantastic and very usable. But only for the first minute or so, because the indexing service starts attempting to index GB-sized XML test files and bogs down the machine... so each and every KDE upgrade ends up in a quest to find what's making the machine unusable, and then disable Baloo, then starting working as usual.
... is that this year you'll never, ever pay less than any other previous year. Even if your system, your user count, your CPU count and everything else has not changed a bit, you'll never, ever pay less than the year before.
Oracle is one of the fewest things that costs more year on year, even when selling more than previous years. Because... Oracle
P.S: yes, you committed to that maintenance fee when you purchased your licenses. However, try to purchase these same licenses again if you're lucky and the product still exists and has not been folded into a multi-portfolio-offering-of-things-you-will-never-use. You'll be surprised that they cost more and carry a higher licensing fee than when you originally purchased them.
So the packages were good and updates by the mantainer were good as long as they were useful. Now, the same maintaner pushes a commit they don't like and it has become "malicious"
It is not malicious, github, that commit has made the package useless. Which is not the same. If useless software repos are banned from github then about 50% of github (unfinished pet projects, obsolete snippets, etc) should be banned also.
mmm... no, the scammed won't pay or lose in the future crypto currency collapse. They have already paid for their crypto currencies. Their losses will be limited to that. Which in a sense, as pointed out in other comments, it is much less than if they were operating futures or options.
Nonetheless, a lot of family savings will be wiped out when the crypto currency bubble crashes. Except of course the "too big to fail" entities, but for the small investors, which are 90% of crypto currency holders (owning less than 10% of the asset's value) will be a financial disaster.
Somehow we, as a collective, never seem to learn: after dot com, real estate, etc, one would have expected people to become more financially savvy.
That's an interesting point, but be aware that the liable areas are so well covered because of their... liability, and that's because something going wrong in those has significant impact on people's lives or wellbeing.
And we have a much, much wider range of applications where the impact of a security incident is likely minimal to small annoyance to actually none. Making these services liable on the same scale as the others will likely put them out of business in short time.
Problem is, sometimes you activate the touchpad while moving your hands over the keyboard. Not everyone is a formally trained typist and I hate when the cursor starts jumping around because my hands are positioned not just right where they should be so as to not activate the keypad.
That is completely tryue for organizations that cannot justify the cost of full time staff with expertise in all relevant areas. Thus, this is applicable for small organizations.
Not for big banks. Banks that outsource do it for two reasons: either move IT from one cost center to another or buy services (e.g cloud) where even their size cannot compete in scale with really big IT providers.
I did not said that all of the UK wanted to leave the EU, I merely stated that these things are consequences of Brexit. Unfortunately, the remainers are equally affected as the leavers. But the impacts are there, which is what my statement was about.
Ok, let me rephrase that as: "there are shortages of (lorry drivers/plumbers/painters/crop collectors....) everywhere, but for some reason the only place where these shortages lead to supply chain shortages is the UK. Brexit is they key difference between places where, in spite of having shortages of (lorry drivers/plumbers/painters/crop collectors....) these things do not impact the supply chain so severely and the UK"
Best described as "UK shortages of lorry drivers" Seriously. Those who live in the rest of Europe can asses that there are no shortages of... anything at all, much less lorry drivers. Except computer chips for those customers cheap enough to get them for cheap (automakers). You brits should be honest about what the consequences of Brexit are. Yes, pandemics made the problem worse, but there are no "worldwide shortages of lorry drivers" anywhere in the world except in the UK
It is when you compare SQL Server on Windows vs. its Docker container counterpart. Note that I have not seen a single benchmark where you can tweak Postgres to run at least on par with SQL Server, if not faster. Since you have to get permission from MS to publish a SQL Server benchmark, this is somewhat expected.
And don't forget that the docker image eats memory like mad, so when you want to sping up a small dev/qa/test instance the SQL Server docker container will eat half of your machine just because it can't be bothered to change its configuration. This is unlike Windows where you can trim down SQL Server not to be a memory hog.
While your comment is spot on, you're ignoring that IBM lost is dominant status a long time ago. Technology and business changed faster than they could adapt, and the IBM way of keeping profits up has been so far an on going exercise of cost cutting actions that exchange short term benefits for long term survival.
On business of the IBM scale you can do that many, many times to keep these profits up, until there is nothing to downsize/offshore/layoff any longer. And IBM is approaching that point now.
True for a lot of people. Including me. My ZX Spectrum 48K original case (the inner board went inside a customized keyboard to which I wired a reset button on my own) looks a bit older today.... He's not only responsible for my career in SW development, but also for my learning of english out of the desire to understand how to program that thing.
I raise one for the man. Godspeed, Sir Clive Sinclair
<<Rights aren't rights if they can be taken away>>
Rights do not exist in vacuum. In particular, exercising your rights should not be at the expense of someone else's having to drop their expectations of their rights being exercised. In this case one's "right to not vaccinate" collides with other's "right to live healthy and not die of a highly contagious but preventible disease" and to fit the two together in the same society means compromises. For both sides.
Just because something is non-mandatory, that is, you're free to decide if you do it or not, does not mean that when you take your decision you won't have to deal with its consequences.
The key here is to inform yourself of the consequences. With the amount of misinformation esp. related to denialism that is circulating, many people may fail to understand fully the consequences of their actions. But that is no excuse for not assuming them.
So yes, you're not required to get a vaccine shot. But also yes, the consequences are there and you'll have to bear with them. That is not forcing you, same as nobody forcing you to smoke or drink.
Ha, those "I could fix this in 6 months if empowered" usually denote an inmense lack of awareness of the environment. In complex environments with multitude of legacy systems 6 months is the time you need to just know what are the impacts of your changes
"bunch of guys who went to prep school together, then on to Ivy League schools and jobs on Wall Street or in big corporations, and think they're entitled to screw the system and get richer than they already are, and feel they're untouchable"
You may have seeded here the next Hollywood blockbuster movie...
And I've never ever missed any of these loads of features mentioned. I bought it back then for 14 quid, when my company got an employee discount as part of a license deal with MS. This shows that there's actual value in owning rather than renting software licenses.
MS should be careful when pushing these price increases to individuals, some of them may find that LibreOffice does everything they need...
Don't know what is this "robustness" you're talking about. The early internet was way more unstable, starting with the last mile (phone lines, yay!) down to very little, if any, redundancy on the physical layer. The things is, the early internet was way, way smaller than it is now and thus incidents such as this one impacted very few people, services and businesses.
You're right in that the consolidation you mention has happened, but was unavoidable. In any mature market -all of them, not only telecomms- there is just not enough room for more than a few big players. It is safe to assume that if one of these players starts to under perform in some crucial dimension (reliability, performance, cost...) some other will quickly attempt to grab its place.
Once again, Postgres is superior in that regard. I recently moved a largish app from MariaDB to Postgres and luckily there was very few custom SQL to deal with. Was not without quirks, however. Worth doing it as the number of concurrency issues went from four or five each day to once each two months or so.
ahhh, the SQL Server docker image. Yes, it does work. Which saves a lot of hassle when you're executing automated tests under Linux CI. But said image is also a memory hog, takes ages to start and is generally considered a lesser evil that avoids having to set up a Windows machine instance just for running a test.
Until you move away from SQL Server, that is.
Or dogfooding, call it they way you want. Now IBM employees can enjoy the level of support and care they give to their own customers and watch with their own eyes the fine art: of deflecting blame away to the customer (IBM), the level of ignorance about their legacy systems (cost cutting took away the veterans because they could be replaced by young and inexperienced people from cheap labor countries) and the jarring level of ignorance on basic computing concepts from the aforementioned young people.
I'd understand to ask for two weeks to create a custom package based on sources that has to be compiled into a binary, installed to a non standard specific location, set some environment variables, etc.
But 2 weeks of engineer time to donwload a binary and create a package that invokes the installer bypassing user prompts is simply either fraud or using a very, very, incompetent engineer.
<<this falls on the shoulders of the people who thought it would be better (read: cheaper) to outsource. They always look at the top line and miss the devil in the detail.>>
You forgot to add: these people make sure they are not around when the true, actual costs of outsourcing are realized. By that time they have already collected their saving targets bonuses and have moved to another organization where they are treated as star innovators (and have agreed another huge bonus for doing exactly the same thing)
The cycle ends when they retire or move as executives of one of their outsourcing partners.
Oh yes, and... where is the formal proof that proves that your formal proof is correct? And so on. I thought this debate was settledd a few decades ago... yet there is still people that think that something above the simplest of systems can be proved "secure"...
<<If there's enough demand and it can be done profitably, someone will offer it.>>
If there's no alternative, no matter how many people want or need a cheaper roaming rate, nobody will do it. Why drop a substantial and essentially free revenue stream when there is no need for competition?
And this is because they are "start ups" If they future were not so uncertain they would be called "established business" instead. Now, seriously, I read an statistic some time ago that 9 out of 10 small business, regardless of being technology based or not, don't last more than two years.
Good idea. However I'm sure that out-of-process will fight with the internal Office machinery because that assumes everything is running in-process. Which likely is a decision dating back to the 32-bit Office/COM days and that in turn requires porting of yet another piece of legacy Office code that has not been touched in decades, possibly breaking existing add-ons in the process.
Of course some add-ons won't we never ever ported and that will leave a trail of machines running old Office versions forever, much like there are still XP boxes around running old software.
History repeats itself.
I've a close relative that is starting to drift into long term unemployment territory, while I've switched jobs twice in the last five years, always improving pay scale, quality of life, and fun while working. A month or so ago he asked me how could it be that I keep getting job offers without even trying or actively doing anything while he was not being offered nothing above entry level work, if at all. I took a look as his online CV and discovered most of the flaws mentioned in this article: no keywords, no tailoring for what he wanted, missing concrete deliverables and achievements... and pointed him to them.
But this is a much better articulated and exhaustive summary than I ever would be able/willing to do. So I'm forwarding him a link to this article.
Been there. At first I had the same opinion as you. But no, these kind of systems are not triggers 2.0 because triggers have a number of drawbacks:
1- Trigger code is database dependent. It is much easier to drop a module of this type already tested by someone else than try to develop DB specific code to push a message into some kind of message bus. For each DB engine and version. And I've been in places with three different DB engines in at least two different versions each.
2- Depending on the DB, not all operations invoke triggers or there are specific commands to disable triggers during execution of other statements. This is usually done for performance reasons, and as such...
3- Withou rigorous inspection and review (and even with those by accident), trigger code easily can become a bottleneck, something you do not want when you're interested in your DB transactions being commited as quickly as possible.
Triggers are wonderful when you have no other means of expressing a business domain constraint and want to enforce it at the database level (those that say that these constraints can be enforced at the app level have a special place in hell filled with junior external consultants banging directly on a database violating all business constraints and repeating "but it works for my use case") Triggers as the foundation of a data bus are one of those ideas that look good in your head but become headaches on the medium term. That's why these kind of tools exist.
Every single tool that extracts data from Oracle is a potential candidate to apply one of the many, many different licencing scenarios that Oracle keeps changing and adapting as technology evolves (mullti core CPUs, VMs, cloud...) in order to keep their revenue stream growing. Just bear that in mind before dreaming up that system that allows you to get data out of your application and into a less expensive (or even free of licensing) platform or into many, many more hands. Oracle has a dedicated team devoted to evaluating how big is the "gap" between what they think you should be paying and what you're actually paying. If that gap is big enough, Oracle has no problem suing its own customers. Google for recent examples and you'll see what I mean.
The only way of avoiding Oracle licencing headaches is to completely stay clear of any of its products. Even free ones.
Given the ratio of overstaffed management (multiple layers, on-shore, blame shifting experts) vs. understaffed technicians (off-shore, young and and inexperienced if not likely underqualified) at IBM, the meetings where they perform their required-by-process RCA analysis could probably be the source of a Silicon Valley comedy script.
<< Your data is in a DB to which you have full access and control>>
Really? You worked on a different SAP than I did back in the day. You could not even login to the DB with any credentials at all, because the SAP staff could refuse to support you on the grounds of uncontrolled changes to the environment.
And even if you manged to get a DB account (of course with limited rights), you started to run into those nicely "packed" rows where in their infinite wisdom, SAP decided to encode in a single database row the contents of one or more of their "entities", so you could not extract data with raw SQL but instead had to go thru the time consuming ABAP extraction.
The only fun part of all that was hearing how the SAP staff called these tables "encrypted", as if the information was in some form transformed to prevent you reading it. It wasn't. The reason for these "packed" tables was that SAP ABAP programs used nested loops instead of using database joins, fetching one row at a time from the DB for each one to many relationhip. This was a huge performance penalty in multi million row jobs. So instead of fixing that, the SAP engineers created yet another layer that avoided performing the join operation inside a loop by serializing the joined rows together in a single database row. Of course, that meant that you would not ever be able to read those rows with a SQL SELECT statement, but who cares about openess and integration. Also, why learn about database joins, or query optimization.
So much to have full access to the DB...
Biting the hand that feeds IT © 1998–2022