rowland66
rowland66 on Hacker News
I believe that when you license Weblogic from Oracle, the Weblogic license includes a license for the Oracle JVM it runs on. So there is no reason to run Weblogic on another JDK/JVM. I assume that Oracle requires their JDK/JVM for Weblogic to keep support simpler.
It is not shown, but I expect that Oracle EE is probably the most significant contributor to software licensing costs. If Oracle licensing was computed for 288 cores, that is totally unrealistic. Oracle EE would only run on a subset of cores.
An alternative implementation of BigQuery? If the integration libraries are that bad, perhaps the market would go for a BigQuery alternative with better integration support.
I expect that the integration libraries probably work pretty well for most users, and implementing a database like BigQuery would be a massive amount of work. So this pretty much explains why Google isn't sprinting to fix this issue.
> You don't pay investments back. They are a purchase of shares. The exchange is made and you're done.
This is a common misunderstanding that equity funding is free. For the owner of a business, taking outside investment and issuing share in return is diluting the original owners stake in the business. If effect, you are paying for these investments forever because you are giving up some portion of the businesses future profits.
There are certainly situations where this makes sense if you are able to grow much faster with the additional capital. However, the investment is not free.
Why is this guy being called an inventor? The helicopter was invented over 100 year ago (1907). He was a tinkerer or hobbyist.
The US is absolutely shooting for herd immunity now. Its just a question of how individual members of the herd want to achieve their immunity. They can take the easy way (vaccination) or the hard way (get Covid).
There has been alot of innovation in digital payments in India over the last 10 years. There are a number of local alternatives to traditional card brands. This might be a combination of protectionism to support local payment alternatives, and international card network unwillingness to invest in India given declining market share.
How about adjusting the tax rate that is paid on income based on wealth? This would absolutely complicate the tax code for wealthy individuals, but it would certainly increase the tax paid by the wealthy on the income that they do have.
I think that Sayre's law applies here. "In any dispute the intensity of feeling is inversely proportional to the value of the issues at stake."
Starting with Java 8, Java has been adopting functional programming ideas, and appears to be heavily influenced by Scala.
From the article:
> But if you need some complex algorithms — particularly algorithms that do a lot of heavy mathematical lifting — then Lisp is the ideal choice.
Is this right? I never thought of LISP as good fit for numerical processing.
I agree, and packages and package private access is such a powerful tool in Java, that so many developers completely ignore.
Wow, that is pretty basic economic fallacy. Whether you hold coins today or not should not impact an investment decision. If the BTC you bought 10 years ago for $100 is worth $100,000 today, and a couple of weeks from now the price collapses and is worth $100 again, you have still lost $100,000. Just the same as if you paid $100,000 for your BTC today. Only difference would be tax liability.
That first sequence diagram in the article reminds me of similar diagrams that I have seen for microservice based systems recently. Progress? Not so sure.
I think that you have the option with Quarkus to use the traditional JVM with byte code for development, and only generate exe's for stage or production deployment. Best of both worlds.
Yes, the OP has this backwards. The Java sandbox would allow an application to limit the access granted to a library to protect from a malicious library. It does not protect a library from being used by an application in way that was not intended by the library creator. It is certainly not a means of enforcing a licensing scheme.
I think that there are alot of advantages to a using a declarative/functional programming style for these types of tools.
Looks like Power Fx could benefit from a dose of Haskell point free notation. Might help eliminate some of those parenthesis.
That seems completely irrelevant.
So it looks like Taler is designed as a consumer to merchant payment system, and not person to person. I suppose that person to person could work with banks serving as intermediaries.
With anonymity for consumer how would transactions like exchanges and returns work?
I think that it is called an immediate annuity. It is a standard insurance product that offers protection against outliving your assets. You pay a lump sum in return for a guaranteed income as long as you live. Yes, if you die early, the insurance company wins, if you live longer than expected, the insurance company looses.
I think these are more common in Europe where people will often take a lump sum pension payout at retirement, and buy an immediate annuity.
I think that it is a mistake to call this a UI issue. Its not like a mistake was made because text was difficult to read, or because to check boxes were too close together and the wrong one was checked. Those would be UI issues.
This was an issue of an operations team that just did not know how their system worked. Perhaps the system design could have been better. Most likely it could have been, but if Citi had a team of people using a system responsible for billions of dollars without the competence to use it correctly, that failing goes way beyond the UI.
Looking at the screen tells you nothing about the quality of this system. The screens look a bit dated because the system is 20 years old. It is also a back office system used by a small number of what should be trained professionals. Pretty html and javascript would not have helped. This was a failure of the whole system. The software and the organization.
Your experience with Citi is very similar to mine. It is funny that as an organization Citi seems to believe that its technology is brilliant and that any software that it uses must be built by Citi. Tremendous hubris combined with total incompetence. Not a winning combination.
If your goal is to buy and never sell, then btc is the ideal investment. You can buy the btc, destroy your private key, and nobody will ever be able to sell it, not even your grandkids poking around in the attic 20 years after you have died.
I think that the first sentence on the why Pony page says it all
"There’s plenty to love about Pony, but more than anything else, what we love most is that Pony makes it easy to write fast, safe, efficient, highly concurrent programs."
In Erlang you can write safe highly concurrent programs, but you might struggle with fast and efficient. Of course, how much fast and efficient you need depends on what you are trying to do.
I don't really think that a comparison to Rust is all that useful. Rust and Pony are really intended for different purposes. Rust is systems programming language. Pony is an application programming language that provides an actor model for concurrent programming and a runtime to support the actors and perform garbage collection.
A valid comparison would be to compare a Pony program to specific type of Rust program that involves considerable concurrent processing of data.
Pony's killer feature is a type system that allows programs to be written that are guaranteed to be safe from concurrency bugs. Like Rust, the Pony compiler is based on LLVM, and Pony programs compile to native code. Due to the Pony type system, the Pony GC is very efficient. Pony performance is pretty good, but as a language Pony is about much more than performance.
> It could be the case that every message you send gets dropped due to a persisting partition and in such a case none would arrive, thereby violating the "guarantee" of exactly-once delivery.
That is not correct. All interactions between the client and the broker are performed in transactional units. If the transaction in which messages are sent fails to commit, then the messages are not sent, and all work is rolled back. Once a message is successfully send (that is, sent and transaction committed), it will be delivered once and only once to the receiver.
Likewise on the receiving side, a message is delivered and the encompassing transaction is committed once and only once. A message may be delivered more than once if the encompassing transaction is later rolled back due to say network failure. But a message delivery in a transaction that does not commit is not a delivery.
The benefit here is that application programmers don't need to concern themselves with message duplicate checking and the risk that duplicate checking is done incorrectly leading to bugs that are very difficult to identify.