"But our BoD has seen the full writeup on Nintendo (and Valve) and they are fully supportive on either if opportunity arises as am I."
(emphasis mine)
Oh please God no, not Valve. MS has changed pretty dramatically since the Gates/Ballmer days, but Valve is way too valuable to computer gaming to be owned by a company like MS. Luckily Valve is privately owned, and even if they were public, their valuation would/should be pretty insane. So I think anyone buying Valve is unlikely.
Valve may be the single greatest asset to desktop Linux at this point (after Redhat, possibly), and it would be such a shame to have all that destroyed.
Even if I still played video games, I wouldn't care what happens to Valve. They were the reason some games forced you to install this Steam nonsense and launch it every time to run em, which seemed to just be for DRM purposes. MS would probably do something just as annoying, though.
This looked pretty cool until I found a price: ~$100.
Lots of cool features, and it's a beagleboard, so there will be actual support/documentation/source. But I'm not sure $100 is "affordable" for the SoC you get and the small 2GB of RAM.
> The price is exactly where it belongs without Broadcom subsidizing things so they can be given away.
A bazillion mobile phones with similar cpus, ram, AND screen, cameras and other sensors, battery, bla bla bla aren't being subsidized. Lots of them are at similar price levels.
As I mentioned in another comment, 2GB is the maximum memory size that all of the processors within the SOC can access, so it's a perfectly reasonable amount of RAM to spec for this SOC.
The Cortex-A CPUs can access more than 2GB but because that memory requires more than 32 bit addressing, the other processors cannot easily access it.
This is a common theme in similar TI SOCs. For example, the AM57xx SOC which are used on the Beagle-X15 and Beagle-AI can have more memory available to the Cortex-A15 than can be possibly made available to the DSP and Cortex-M4 processors. The Cortex-A15 has a special interface to the memory controller which enables extended address use beyond 32 bits where-as the other processors and subsystems within the SOC are all attached to a bus where 32 bit addresses are the maximum.
> The Cortex-A CPUs can access more than 2GB but because that memory requires more than 32 bit addressing, the other processors cannot easily access it.
What's preventing the 32-bit CPUs from accessing the full 4 GB of a 32-bit address space?
The main memory map places the DDR memory starting at 0x8000_0000 up to 0xffff_ffff in both AM62x and AM57xx. Below 0x8000_0000 are a bunch of other memory mapped devices and interfaces.
Additional memory beyond 2GB are all located above 0x1_0000_0000 address.
Before I tell you kids to get off my lawn, there was a time when development kits were thousands of dollars, and only if you had a good business relationship with a chipmaker.
TI actually had BeagleBoard (not BeagleBone) and PandaBoard for OMAP long before RPI came along. Those were nice, but still were close to $200. Probably $300 in today's dollars.
Yeah for a while before RPi and Arduino embedded/DSP dev hardware was pricey. I still remember when I worked for ADI that their “EZ-Kit” SHARC and Blackfin development boards were insanely expensive, >$500 each or so. The real kicker was that the JTAG emulator you programmed it with with cost thousands of dollars. Never made sense to me, I always figured if people were putting in orders worth millions, why not just offer dev kits and software for some nominal fee.
Someone later produced a cheaper Blackfin dev board called the “STAMP” and sold it for ~$100ish and worked to support uCLinux and a GCC backend. Picked one of those up and did a bunch of hacking in my own time, really fun stuff.
And before JTAG you had in-circuit emulators which could cost tens of thousands of dollars. And even today we're spoiled by Seeger JLink. The Lauterbach tools used to be the only game in town for ARM besides ARM's own stuff and it was all crazy expensive. But it was pretty powerful too.
And back in those days if you were a high volume customer you got all the development tools for nothing. But that didn't help startups and tinkerers at all. Hacking hardware in the early days was not easy.
No, this is what parts cost, don't let Broadcom fool you with the RPi SoC.
This TI AM625 is around $18 in high quantity. When you add in all the connectors and DRAM and the PCB/assembly it sure looks like a $100 retail cost is almost selling it for no profit.
The optimizations that went into this must be pretty impressive for it to run as well as it does on my Framework laptop (11th gen, no dGPU). I did have to run it in Chrome since Firefox gets the "unsupported browser" error[0]. Glad I tried it out since typically "I made a voxel engine" wouldn't catch my attention. ;)
[0] console: "WebGL warning: readPixels: Format and type RGBA_INTEGER/UNSIGNED_BYTE incompatible with this RGBA8UI attachment. This framebuffer requires either RGBA_INTEGER/UNSIGNED_INT or getParameter(IMPLEMENTATION_COLOR_READ_FORMAT/_TYPE) RGBA_INTEGER/UNSIGNED_INT."; Firefox 104.0.1; openSUSE Leap 15.4
I've actually spent the majority of development time on optimization rather than actually working on the overall product. The choice to create this project in the browser instead of native certainly made this more challenging! :>
And thanks for the report, I'm gonna give this another try to fix, and otherwise gonna forward this to the Firefox devs.
Not to be "that guy", but could you please put the language in the title when posting stuff like this? We all have our language preferences, and I'd rather not have to go digging just to figure out if a project is relevant to me.
It says it's a "web framework" in the title. That generally means it's going to have some kind of templating system, plus html, css, JavaScript, and probably support for other things like markdown and json. Which of these did you want in the title?
Or if you mean what was astro itself written in, I think this post is aimed at users of the system, not potential contributors. Personally I dislike it when when a post says something like "Hugo, a static site generator (Golang)" because it incorrectly implies you need to write Go in order to develop with it.
When I see "web framework" I think Phoenix, Django, Spring, etc. Which do all require you to write in the associated language. If you said "Static Site Generator" then yes that doesn't imply you need write in a specific language.
As a counterpoint, I experienced the exact opposite. I got tired of deb-based distros leaving me in package limbo if something went wrong. I'm sure there's an easy fix, or maybe the entire problem is fixed now, but I've been a very happy user of opensuse (and just suse before that) for a long time - well over 15 years now. I love their huge range of optional software repos. I can have a nice stable base system with only certain software bleeding edge.
Very cool! I was excited & shared this with everyone at my small SaaS company... then I saw your pricing. :( It's literally an order of magnitude out of our price range!
Thanks for the feedback. At this point we are targeting slightly larger SaaS companies, though we hope to bring this to a price point that's feasible for every SaaS company eventually!
> If you want up-to-date software from your package manager, use a rolling release distro. Otherwise the best you can do is something like a base setup and then side-load the software you want. This problem has been identified to the point where there are several brew-like systems (and things like snap as well), but no clear winner yet.
I use openSuSE Leap with a bunch of OBS (build service) repos added. I get a nice stable base OS with updated packages when I want them. And it runs KDE/Plasma nicely, too, and not as an afterthought or something like other distros.
On https://www.pingcap.com/docs/sql/mysql-compatibility/ it mentions "FOREIGN KEY constraints" under unsupported features. Is that right? Isn't that a rather big problem for an OLTP DB? Or am I missing something?
Greg from the TiDB team here. I do share your sentiment, and at the moment you can probably best track or progress on this issue here: https://github.com/pingcap/tidb/issues/8484
The explanation is just that TiDB is being developed with tight feedback from our customers that have many TB of data. The feedback from that scale of users is overwhelmingly that they do not want to take the performance hit of foreign keys. It is worth mentioning though that you can declare foreign keys and that on master we do properly check DDL statements (but there is no DML enforcement).
I am trying to figure out a design that will satisfy users with large and small data alike and even let users use foreign keys for documentation purposes when they are not enforced for performance reasons. It would be great to have more community input on this.
Yes, that is correct. I hope to see FOREIGN KEY constraints added in the future.
In the interim though, when comparing TiDB to (application) sharded systems, it is important to clarify that FOREIGN KEYS will only be available locally to a single server. So it is a limitation that some of the large deployments we encounter are already familiar with.
(emphasis mine)
Oh please God no, not Valve. MS has changed pretty dramatically since the Gates/Ballmer days, but Valve is way too valuable to computer gaming to be owned by a company like MS. Luckily Valve is privately owned, and even if they were public, their valuation would/should be pretty insane. So I think anyone buying Valve is unlikely.