I've spent a whole bunch of time on CoolBeans (now OpenBeans http://www.openbeans.org), a "distribution" of NetBeans.
I assumed it would be possible to do a lifestyle business out of catering to a subset of the over 1M NetBeans users. Turns out it is not so easy.
I spend some money for a Windows machine to digitally sign builds, the macOS dev certificate and hosting. But the bulk of the cost was the time it all took.
PS: The .xyz domain in combination with the Windows antivirus solutions (looking at you ESET) was a major annoyance. Switched to .ORG just in time for the whole debacle there.
I had no clue about this situation but it doesn't look very well. Introducing continent-wide IP-law for seeds, getting farmers into debt by having them used only approved fertilisers and then showing virtually no productivity increase against the baseline shows no redeeming quality to the program.
But hey, Gates will be declared a saint in the next 10 years so who is this little mag site to comment?
The program follows practices already common in the West. That means it makes it easier to convince Western companies to make long term investments there without fear of some arbitrary action to their assets (cough-Sakhalin-2-cough).
But yeah, important thing is that the western upper-middleclass has a convenient boogeyman to vilify in a digestible form for day-time viewing.
That sentence is just more question begging. "Running things the way it is done in the West (i.e. encouraging 'investment' by Western firms) is good, therefore a program which furthers that end is a good one."
The burden of proof is on the individual claiming that agricultural investment by Western firms into Africa is a negative, given that it's commonly believed that FDI is a good thing and African governments routinely and actively seek out FDI as part of their policy. So I don't believe that to be question begging.
The program is supposed to improve agricultural yields and they claim it did not. Is the program just about helping Western investments? So the investments result in unchanged yields?
What I have said was that the measures taken are means of attracting direct investments from Western countries. As an example, I've given the Sakhalin-2 project, where the Russian state essentially raided away billions of Western investments to the benefits of their chosen oligarchs.
What I have implied here, in case it is not clear, was that the Jacobin either willfully misinterprets facts or makes constant pleas to emotion of sheltered Westerners to sell their store-brand let-them-eat-cake progressivism.
1. I didn't say they were wrong, I said facts are being misinterpreted. That means that even if we assume the facts in the article are true, the interpretation of those facts isn't being done objectively.
2. If you are going to talk quantitative, please start with a concrete definition of the KPI and how you calculate utility and cost.
If you are looking for concrete examples of how you are being manipulated by the article, then to name just a few example:
- The article drops analytical rigor just at the exact moment when it benefits their narrative. For example, the 2020 goal of the initiative was a projection based on certain assumptions. To say if the project has failed or not according to those projections, the assumptions must hold. Funnily enough the article doesn't list those assumptions anywhere or address whether those assumption still hold true, or even if they were valid to begin with.
- The article uses language to imply malice, where there is none. For example: "Moreover, freedom of choice is restricted: in AGRA projects in Kenya, small-scale farmers are not allowed to decide for themselves which corn seed they plant and which fertilizers and pesticides they use on their fields." Gasp, horror. An investor wants you to follow their rules. How dare they. Jacobin should be on the barricades that VCs don't allow you to spend their money on a new Porsche, because that limits your startups freedom of choice!
- The article talks about agroecology as if it's as of now a viable alternative. Unless there's tons of investor capital lined up behind it, it really isn't. In fact, these aren't even comparable things.
I agree that the site might have an angle and I don't believe their alternative solution (agroecology) is any good. Still, the article seems to showcase some questionable points about the AGRA initiative.
The whole idea of introducing IP law for seeds to improve yields then show a 17% increase, just like the baseline, seems a monumental mistake.
The fertilizer situation is questionable too. If they put so many conditions then they should also guarantee some outputs. Otherwise there's no risk for them, only the farmers. But I grant you that whole section seems a bit shallow.
You set a pretty high bar to criticise such huge initiatives. They can fail based on the externalities they create, not only as a model that guarantees an output given some assumptions.
> Still, the article seems to showcase some questionable points about the AGRA initiative.
And that would be a fair criticism. The problem I see with the article like this is that if we are talking about problems that need immediate or at least short-timescale solutions, you often don't have an optimal choice. You might have a choice that's somewhat less shitty. All the hand wringing isn't productive in the best case, and is a deliberate political tactic in the worst.
Hence, I think that the "angle" situation is a serious one. There are a lot of right-wing and left-wing outlets that push an angle that often muscles out any objectivism out of a topic.
> The whole idea of introducing IP law for seeds to improve yields then show a 17% increase, just like the baseline, seems a monumental mistake.
IP laws for seeds are a mistake in general, in my opinion. The optimal solution would be to either soften or repeal IP laws for seeds. Can we attain that short to midterm? Probably not. Does that mean that nothing should be done? No. So we are left to work in a space with solutions of varying shittiness, which still worthwhile to engage.
> You set a pretty high bar to criticise such huge initiatives. They can fail based on the externalities they create, not only as a model that guarantees an output given some assumptions.
I don't think so, but that is more the result of how I understand the word "fail". I think it is fair to say that the initiative has failed to achieve the hoped for results due to reasons A, B, C, etc., one of which is that the initial assumptions have proven to be wrong. That way it is pretty transparent.
I don't understand the hype for RISC-V at all. It's an instruction set that would... just require a new backend for clang/gcc/Java and mean nothing to me unless somebody makes something that just obliterates a Ryzen.
Why should developers care? We barely have a decent ARM ecosystem after years of ARM routers and Raspberry Pi. Now we are supposed to be enthusiastic we will do that yet again for RISC-V?
Is it because it's somehow more open? But ARM wasn't that closed afaik - lost of folks produced it.
And Sun Microsystems open sourced a 64 thread CPU, the OpenSparc and nothing happened.
On example of this is Esperanto Technologies, which has created an SoC with slightly more transistors than the M1, which has over 1000 RISC-V cores which implement the RISC-V vector instruction set extension to allow the processing of a large number of matrices and vectors. Basically the ET-SoC-1 as they call it is supposed to offer superior performance in the Machine Learning domain. 30-50x better performance with 100x less power consumption.
Esperanto Technologies are using the full flexibility of RISC-V by having more general purpose RISC-V cores, four of them, which are meant to run an operating system, which schedules machine learning tasks to this large number of smaller vector oriented RISC-V cores.
My understanding is that creating a good ISA is actually quite a task. RISC-V has over 1000 contributors over years who have made it happen. Esperanto Technologies apparently began with their own proprietary ISA for their coprocessors but found they could not beat RISC-V, and that making something better would just cost a lot more money and resources.
So in short the value proposition is in having a highly customizable ISA, that is well designed. There are no such other options on the market. ARM isn't highly customizable, since it has over 1000 instructions you must implement. RISC-V only has 47 instruction you must implement. All fairly simple ones.
>> There are no such other options on the market. ARM isn't highly customizable, since it has over 1000 instructions you must implement. RISC-V only has 47 instruction you must implement. All fairly simple ones.
I think this is a wrong comparison. There is a subtle difference here that is being missed.
CPU's become bloated over time as they get used differently, as the applications shift, as they try to address newer areas. And with each iteration, they still have to support the legacy code. That is how you end up with thousands of instructions
It is easy to have a lesser instruction count when you are starting from scratch and have no legacy.
What is going to stop RISC-V from becoming another ARM or perhaps x86 even, in another couple of decades ? When it spans such a large application space that most of the extensions become default and the core becomes bloated ? Time for another ISA then.
No, because verification tools are made to verify that you don’t take an extension for granted. Compilers as far as I know are made to generate code for different extensions. The CPU also contains registers to check what extensions are present.
ARM is what it is because license holders are required to implement the whole ISA. RISC-V is kind of the opposite. You are required to assume extensions are optional.
And OS is supposed to trap instructions not implemented and jump to a software emulation of them.
I don’t know all the details. But the point is they are planning for this from the start and building their tools around this. That was never the case for ARM or x86. Hence it is premature to assume it will end up the same.
It's time to talk about a completely different domain that makes programming be heaven. In electrical engineering there is no such thing as a generic component. There are only implementations of them and you have to pick among the company provided implementations. Imagine if you had to specifically choose a 4Ghz grade if statement in your programming language or make sure your while loop supports 1.3V on the CPU. You need to have a good mental model of how the statement are implemented to choose the right one.
That's how bad electrical engineering is. Programming is bliss in comparison. You can do the dumbest things and it still works out. Your computer will never go up in flames even in the most bug ridden C code base. RISC-V will bring this to a lesser extent to software development. There will be no "general" RISC-V CPU. Instead you have to constantly worry about whether your CPU supports these instructions. Implementing fallbacks will just cause very inconsistent performance drops among CPU manufacturers. Think of things like the Intel compiler disabling SIMD on AMD cpus except this time it's because the manufacturer didn't bother to implement a "bloated extension" where only one instruction is actually used but when it is used it's in Fortnite or some other popular game so you do extremely poorly in benchmarks.
The issue is not whether SW can work around optional extensions. The point is that if you want a general purpose performant cpu (like ARM/x86) targeting a wide swath of applications, you will end up with these optional extensions as default. And then it is as bloated as others. We are not talking about micro-architecture optimization here to make it more performant, but isa architecure.
Ofcourse, you can change the computing module to minimal base isa and specific accelerations in ISA/HW. But then you will be restricted to niche applications and never replace the incumbents for general purpose workload.
>> Hence it is premature to assume it will end up the same.
And it is wishful thinking that it will happen otherwise. Whether ARM/x86 thought about extension from the ground up doesn't matter if you are targeting the same application space as them.
I have not seen anything done to even acknowledge this issue, let alone do something about it, for the simple reason that this lies far into the future and has no impact on the current scenario.
Given time and legacy software, it will morph into one.
> The point is that if you want a general purpose performant cpu (like ARM/x86) targeting a wide swath of applications, you will end up with these optional extensions as default.
Yes, but the number of instructions is still minuscule compared to ARM and x86. It am sitting with the reference sheet here in my hand. It is just two pages. Very quick to read over.
> And then it is as bloated as others.
Eh... nope. A huge number of those instructions exist due to cruft building up over years, not due to an actual need. A major source the huge number of instructions is tons of SIMD instructions which have superseded each other. RISC-V designers have specifically sought to avoid this preferring a Vector extension instead which adds a lot fewer instructions as it is more flexible.
People keep saying that is complex, but several companies have already made implementations of this. Esperanto Technologies is making SoCs with over 1000 RISC-V cores with vector extensions. So it cannot be that complex if they can fit that many cores.
And the compiler technology is better developed for vector instructions than for SIMD.
> And it is wishful thinking that it will happen otherwise.
It is not wishful thinking to assume a couple of lessons have been learned decades later in ISA design. You can just read up on the details about how the RISC-V ISA has been designed to understand how they are able to keep things simple while still retaining flexibility.
> Whether ARM/x86 thought about extension from the ground up doesn't matter if you are targeting the same application space as them.
The flaw in your assumption is that you seem to think all those instructions are actually used and need to be able to handle modern tasks. Tell me how much software today needs special instructions for Binary encoded decimal numbers? x86 is full of that kind of legacy bloating the ISA, with no value to modern software.
> I have not seen anything done to even acknowledge this issue, let alone do something about it, for the simple reason that this lies far into the future and has no impact on the current scenario.
I think you should just read what they have said about all these things. They have thought a lot more about this than you seem to have. They been doing ISA design for many decades and seen problem develop over time. RISC-V is a response to all those problems of the past. To not build yet another bloated ISA with redundant legacy instructions.
ARM licenses and royalties are not free. The royalties are a small but significant cost of a chip (1-2%) and licenses on the IP are a large R&D cost for the designer.
China is obviously interested in RISC-V as their access to the US market is threatened, and they could be a driver of wider use.
India is also focusing on RISC-V, as they do not have their own chip industry yet. Depending on the Western countries for your processors is something any country wants to de-risk.
This seems relevant if my corporation wants to put some $M into producing a thing. But I paid like $200 for my CPU and I would love a $500 Ryzen. Either way, I don't really care if 1% goes to royalties -- my price fluctuates more than that just because of our national currency.
You are not the target market. Maybe someday RISC-V will compete with desktop processors, but at the moment it is most interesting for embeded systems and coprocessors.
Seems fair enough. Still, the hype is so big on HN it does seem like the hope is for RISC-V everywhere. It's like saying soon enough we will all program in Haskell.
It seems unlikely that I’ll ever use a risc-v system in anger, but I’m interested in them anyway because at heart I’m a hacker, which to me means (in part) that I’m interested in technology.
Until recently, the technology world has been shrinking relative to the 90s. I cut my teeth on machines running z80, 6502 and 68k CPUs, and during my early career I developed and deployed on 88k (DG/UX), PA-RISC (HP/UX), SPARC (Solaris and DRS/NX), MIPS (Irix) and probably a bunch I forget. Things were even more diverse (but less accessible) in earlier decades - each system had its own OS, and sometimes more than one (I’ve used RSTS/E on PDP and CSM on System 25...).
Today, everything in the commercial world runs x86 and Linux. That’s it. Even Windows people are using WSL now. There are loads of reasons why that’s good, but the hacker in me finds it dead boring.
So when I see things like M1 or Raspberry Pi or ESP8266 or RISC-V, it reminds me of a time when there was a lot more diversity in computing, where I could wonder about how things worked and read about them and imagine what applications I might have for them. It’s exciting! It gets my hacker juices flowing. And this is hacker news, right?
So despite the chances of me ever using risc-v in anger being approximately zero, I still think the whole thing is fascinating, and I learned heaps about CPUs just from people comparing RV to ARM and x64.
I think that’s the reason the “hype” for RISC-V is “so big”. It’s not because it’s going to be everywhere, but because it’s quite literally hacker news.
> I think that’s the reason the “hype” for RISC-V is “so big”. It’s not because it’s going to be everywhere, but because it’s quite literally hacker news.
I think that's the wrong question to ask. Aside from those writing kernels, compilers, JITs, etc., developers don't need to care, that's the point of programming languages and compilers. Throw a toolchain at a developer and tell them to do it and they can do it.
Comparing RISC-V to OpenSPARC is comparing apples to oranges. One is an ISA, the other is a hardware project.
What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available?
I'm basically always within 10m of at least a half dozen ARM processors, and a handful of 8051s. At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.
Are we talking about RISC-V as an abstract idea, the same way we would talk about the benefits of functional or object oriented programming here?
Or is the end goal to have hardware in stores that people can buy?
Wasn't SPARC a RISC architecture? (Wikipedia says so, but I'm no expert).
> What do you mean by "We barely have a decent ARM ecosystem". Are you talking about the tools to build for those processors? Or the tools to build new ones of those processors? Or the actual chips that are available?
I remember the early OpenWRT / RPi days when many packages weren't even compiling for ARM. Now I think we are in a much better shape. The chips were available, but the software ecosystem was way behind.
> At worst, RISC-V could be equivalent to ARM, without many of the parts that suck about it.
What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.
> What I do know about ARM sucking is that the whole board design makes each product need a customer kernel more or less. Which is why we still don't have a "Linux for your phones". What I've read about RISC is that it's going to be roughly the same: encourage a lot of co-processors which mean custom boards to me and probably custom kernels.
FWIW, this has nothing to do with the ISA per se, and particularly absolutely nothing to do with whether the ISA is RISC, CISC, or something else.
The problem is that like so many other embedded systems, ARM systems don't have peripherals which are discoverable at boot, hence all that has to be hardcoded (or specified at boot via devicetree) into the kernel (e.g. the interrupt controller is model XYZZY and is accessible at address 0xBEEF). So you end up with a kernel binary that works only on a specific board.
The "server-class" ARM systems adhere to something called SBSA which is a specification incorporating things like UEFI, ACPI, PCIe etc. The end result being that SBSA systems can use a common distro kernel just like x86 systems can.
I learned something, thank you! Considering how performant modern phones are I hope all adhere to SBSA or similar so I can install any OS on my phone just like I could on my 100Mhz PC way back.
Because you can't make an open ARM or x86 core. Yes SPARC was open before and not much happened from it, but just because something didn't work the first time, doesn't mean it not a good idea. The world is different now compared to then.
If we ever want to live in a world where we have open implementation that have a huge software ecosystem that is ready, we need an open well support ecosystem.
So, if you don't care about open source, then you don't care about RISC-V. If you do however, you probably should care.
Now that we are producing and injecting industrial quantities of Ψ, any chance this will get incorporated in actual viruses or maybe teach the immune system not to ignore it (or maybe even go crazy about it)?
Taken from the article (probably after an update):
Many people have asked, could viruses also use the Ψ technique to beat our immune systems? In short, this is extremely unlikely. Life simply does not have the machinery to build 1-methyl-3’-pseudouridylyl nucleotides. Viruses rely on the machinery of life to reproduce themselves, and this facility is simply not there. The mRNA vaccines quickly degrade in the human body, and there is no possibility of the Ψ-modified RNA replicating with the Ψ still in there. “No, Really, mRNA Vaccines Are Not Going To Affect Your DNA“ is also a good read.
I would have bet the move would be towards Lenovo + Linux but no, it was a Lenovo running Windows.
Apple gear is nice, but you can't compare the price of a Lenovo having a fast Ryzen with the latest MBP. I bought the Lenovo at 1/3rd the price. Considering the difference I think the bumps I encountered are worth the $$$$ saved.
Not sure what the angle should be here. The founders didn't manage to raise the company; it was soon to be bankrupt. Of course the founders would be wiped out.
Still, they have $300,000 worth of shares and "the buyer has agreed to pay US$10-million to key employees and consultants including Mr. Gagne and Dr. Bengio as part of a retention plan".
Business doesn't always work out. Getting a cool $1M after trying and failing is not the worst thing that could happen.
That's not the market way of looking at it. How will a bankrupt company retain their world class employees? They are one missing pay-check and counteroffer away from moving elsewhere.
The value of Element AI was that by buying it you get all the employees. Had they waited for the company to go bankrupt they would be competing with everyone else trying to buy the IP and the key employees.
> They identified the sequence for the spike protein, plugged that into their vaccine platform, and voila – an mRNA vaccine against the SARS-CoV-2 virus.
A COMPUTER took two days to develop the vaccine. Think about that.
It would be trivial for you to also put a PayPal address, which seems safer for one-off donations.
You might also be tempted to put BTC/ETH addresses but I doubt there's many donors that way.