What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.
Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.
The only reason why this product is still surviving and still works is due to literally millions of tests!
Here is how the life of an Oracle Database developer is:
- Start working on a new bug.
- Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.
- Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
- Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
- Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
- Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
- Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
- Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
- Finally one fine day you would succeed with 0 tests failing.
- Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.
- Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.
- After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.
The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).
The fact that this product even works is nothing short of a miracle!
I don't work for Oracle anymore. Will never work for Oracle again!
I really like wireguard, but one thing that bugs me is the fact that it's layer 3 (an ip tunnel) and has no code to support layer 2 (ethernet MAC tunnel). The downside for me is that you have to manage static ips in the configurations (specifically it's not compatible with ipv6 slaac and NDP). There is https://git.zx2c4.com/wg-dynamic but it's very experimental at the moment.
The level 3-only tunnel is motivated as "the cleanest approach for ensuring authenticity and attributability of the packets" (in the whitepaper), but in fact every claim and routing algorithm described (needed since the tunnel is many-to-one) would work equally well substituting "ip address" with "mac address" (i may be missing something, but for sure it's not explicit anywhere). And indeed imho it would be less surprising to have an "allowed mac address" option in the configuration than an "allowed ip address": it's already common practice to white-list mac address of physical endpoints (in office). I'm toying with the idea of forking the driver code to adapt it to ethernet frames as i don't think it would need any big rewrite but i'm realizing my inexperience in writing kernel code.
Salesforce is essentially a database as a service with some fancy admin panels and prebuilt web interfaces.
The tech is proprietary, and not that fun to work with. [0]
As someone who has worked extensively with Salesforce, the cult like fanbase is annoying. I'll be the first to admit the tech is underwhelming and in many cases nowhere near other modern technology.[1][2][3]
But, I still 100% recommend Salesforce to companies when they ask about it. Why? Data liability. Yes Salesforce is expensive - but you are outsourcing the responsibility of dealing with sensitive data to Salesforce. This is something that they should market more heavily in imo. (at least to sw engineers and CTOs) Realistically many companies are not properly equipped to deal with data, let alone sensitive data. Salesforce may have started out as a CRM, but now it is a solution to that problem. CTO's now have someone to point the finger at if shit hits the fan on an Equifax level. This alone is worth big $$$.
Use LXC and LXD. It's the best of both worlds. Docker is very limiting and already falling short in features. For instance daemon must run as root which sucks. LXC supports unprivileged namespaces so all users of a system can have their own set of containers. Docker insists on being the parent process, That means when docker dies, so do all your containers.. This is really bad...
I've been wondering lately how feasible it would be to build an e2e encrypted social networking service. Just give people a completely secure place to store their photos, build a network of friends, message people, and promote social events without having their data mined for advertisements and government subpoenas.
ZFS has defragmentation built into the very design of it!
It doesn't fragment, it actually turns all random writes into sequential ones, provided there is enough space because ZFS uses copy-on-write atomic writes:
now, for those of us in the Solaris / illumos / SmartOS world, this is well known and well understood. We either keep 20% free in the pool, or we turn off the defrag search algorithm. But now with the Linux crowd missing out on 11 years of experience, I see there will be lots of misunderstanding of what is actually going on, and consequently, lots of misinformation, which is unfortunate.
Recent Google Cloud Engine images have Sshguard enabled by default.
Now I do wonder: does this 'exploit' still cause a log line immediately after each attempt? And also, do iptables firewall rules also apply to open connections, or just to new ones? In the latter case, Sshguard and fail2ban are circumvented for a rather high number of attempts.
Lua isn't part of upstream GRUB; it lives in a separate module, "grub-extras". As far as I can tell, it also wouldn't be easy to extend that with additional functionality or modules without forking it, due to the way GRUB builds out-of-tree modules.
Note that this port of Python is almost as old as grub's Lua; we've been working on BITS since ~2009, and it has had Python support since May 2011.
For reference, the Python port consists of less than 1000 lines of code, most of which provides compatibility implementations of standard C and POSIX functions that Python expects. (Plus another couple thousand lines implementing additional C Python modules like "_smp", "_acpi", and "_efi", but those are getting smaller as we move more code into Python using ctypes.)
Mainframes are very, very extended nowadays. Researchers use them, the government uses them, some big business use them.
From my point of view, there are four "mainframe" concepts, and one of them is not a monolithic mainframe per se:
1. Supercomputers: thousands of CPUs, each with access to a few gigabytes of RAM, which can run massively parallel jobs
2. Shared memory machines: 64-256 CPUs, each of them can access to 0.5-2TB of memory
3. GPUs: Hundreds of CPUs, each with access to 1-4 GPUs and a few gigabytes of RAM, to run highly parallel vector jobs
4. Clusters: Commodity hardware (either racked or workstations) connected by a network which uses a queue system
The first three belong to the modern implementation of the mainframe, the last one is a "supercomputing"-like facility, built with regular hardware.
This brings us to OP's article, and to my main point. There are many research centres, business and government which use them, but there is a trend towards using regular Intel processors instead of mainframe-like vector processors.
Why? Because they're easier to program for. Us at the Barcelona Supercomputing Center have worked with ppc, ppc64, cell, ia64, i686 and x86_64 architectures, and here's what happened.
Some of these architectures don't have debugging/profiling tools available.
I joke with my colleagues about how it has been 10 years from the first CPU with hyperthreading and we still don't have fully automated tools to take advantage of parallelism on legacy code. We know it's difficult to do, but that has to be taken into account when planning to buy a new machine. Old code might run slower on the new machine because of the highly parallelism but lower raw speed.
Others (cell) are just so difficult to optimize that we needed 2 postdocs working 2 years only to make a matrix multiplication take about 80% of the full computing power. I'll only say that our next machine was going to be a Cell supercomputer, but that idea was dropped after a scientific panel advised against it.
Some months ago I took a course on GPU programming, and for those of you who have never programmed on vector processors, it is like the Hello World in brainfuck. My CS degree+masters wasn't just enough. It is overwhelming. The guy teaching the course was a PhD with 3 year experience programming GPUs, and he admitted that most of the times, if you compare the time it takes for you to program on a GPU with the time you save running the software, it is just not worth it. Hey, sometimes it is, and you save a lot of time. But not for most cases. So we're back to regular Intel processors again.
What I'm trying to say is that nowadays we buy machines for different purposes (large number of cores, large amount of memory, large throughput for vector multiplication, etc) but most of them are x86_64. GPUs are an exception because we buy software which has already been adapted to vector operations, but somebody had to spend many days adapting the code.
We work with Intel and IBM and we have access to the most recent CPUs and tools. IBM makes great hardware but they don't have anybody writing a development framework for that hardware, so you never reach even 70% of its peak throughput.
TL;DR: Yes, many companies use mainframes, but most of them try to put x86_64 processors in there, because they are easier to parallelise and there are many tested programming tools available.
It is close to 25 million lines of C code.
What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on that code under difficult deadlines and filled the code with all kinds of crap.
Very complex pieces of logic, memory management, context switching, etc. are all held together with thousands of flags. The whole code is ridden with mysterious macros that one cannot decipher without picking a notebook and expanding relevant pats of the macros by hand. It can take a day to two days to really understand what a macro does.
Sometimes one needs to understand the values and the effects of 20 different flag to predict how the code would behave in different situations. Sometimes 100s too! I am not exaggerating.
The only reason why this product is still surviving and still works is due to literally millions of tests!
Here is how the life of an Oracle Database developer is:
- Start working on a new bug.
- Spend two weeks trying to understand the 20 different flags that interact in mysterious ways to cause this bag.
- Add one more flag to handle the new special scenario. Add a few more lines of code that checks this flag and works around the problematic situation and avoids the bug.
- Submit the changes to a test farm consisting of about 100 to 200 servers that would compile the code, build a new Oracle DB, and run the millions of tests in a distributed fashion.
- Go home. Come the next day and work on something else. The tests can take 20 hours to 30 hours to complete.
- Go home. Come the next day and check your farm test results. On a good day, there would be about 100 failing tests. On a bad day, there would be about 1000 failing tests. Pick some of these tests randomly and try to understand what went wrong with your assumptions. Maybe there are some 10 more flags to consider to truly understand the nature of the bug.
- Add a few more flags in an attempt to fix the issue. Submit the changes again for testing. Wait another 20 to 30 hours.
- Rinse and repeat for another two weeks until you get the mysterious incantation of the combination of flags right.
- Finally one fine day you would succeed with 0 tests failing.
- Add a hundred more tests for your new change to ensure that the next developer who has the misfortune of touching this new piece of code never ends up breaking your fix.
- Submit the work for one final round of testing. Then submit it for review. The review itself may take another 2 weeks to 2 months. So now move on to the next bug to work on.
- After 2 weeks to 2 months, when everything is complete, the code would be finally merged into the main branch.
The above is a non-exaggerated description of the life of a programmer in Oracle fixing a bug. Now imagine what horror it is going to be to develop a new feature. It takes 6 months to a year (sometimes two years!) to develop a single small feature (say something like adding a new mode of authentication like support for AD authentication).
The fact that this product even works is nothing short of a miracle!
I don't work for Oracle anymore. Will never work for Oracle again!