All of the public money spent on going to the moon is really just a way to funnel $$ to a few sub-contractors the actual science value of going BACK to the moon is pretty low.
It takes such a huge amount of people time, effort, resources AND has an environmental impact to launch a payload into space, we should be expending these resources to help solve our societal/environmental issues, not for "showboat science".
Sadly, this view is considered antiquated and anti-technology by a younger generation of people who think what we see in sci-fi shows should be reality (good or bad). And if you don't get that vision then you're some dumb luddite who should be banished from society.
What's kind of remarkable is the onslaught of vehicles, many EV, which have critical functionality issues that are being ignored, but they have WiFi + hotspot on board! And if you want to do basic things with your own vehicle, like get the climate control ready before you leave on a trip you now need an app, a smartphone, and Internet connection and a subscription...to do things that could easily be done via some local BLE or WiFi connection.
I see a lot of car companies rush to make "immersive" driving experiences while neglecting the basics. The Ioniq 5 / EV6 have ICCU issues that are not addressed which can leave the car stranded and the replacement parts have the same mysterious failure modes, the Jaguar I-Pace had numerous failures including a UI that would lag for basic things like changing air conditioning settings, the last generation Leaf (just prior to the current re-design) has battery issues that have forced people to do lemon-law buy backs, the Ford Mach E has a Tesla-style iPad center display that can't be turned off at night so it's a distraction (among other issues with the poor concept), but it has OTA so awesome!
I used Sailfish OS and so did several of my family members for many years. The "vanilla" Linux OS aspect (besides using rpm) makes it trivial to set up things like dnsmasq-adblocking, firewall rules, etc.
Unfortunately, the Sailfish UI itself feels "different for the sake of different" and not because it's functionally more useful. I think the UI is pretty ugly and difficult to navigate. Anyone who "loved" Win8 tiles and/or Windows Mobile flat monochrome UI always praises the SailfishOS UI but outside of that small group I don't think the UI is that functional. It's definitely eschewed it's MeeGo / Nokia N9 UI heritage.
What always surprised me about SFOS is despite running on some pretty decent hardware, the UI always felt sluggish, especially given it's kind of reversed-big-text UI paradigm which shouldn't take much work to render.
I'm glad there's an alternative, but sad it's hasn't seen a reasonable set of UI improvements despite its age.
I still use Sailfish daily. I have no problem with the UI, but their Firefox is seriously outdated and predictive text for the keyboard is no longer available.
Frankly, the "need" for custom silicon seems self-imposed, with the idea of appearing to be a technology company first rather than a car / vehicle company.
Cruise automation was also for years working on custom silicon, I knew people there. Many people working on the custom devices didn't really believe in the mission statement either, but they were paid well, and got to do fun work, so they took the job.
What makes Rivian, or Tesla better at making the "normal" car pieces compared to Toyota, or Honda? The answer is they're really not better at those things and quite worse typically ; bad fit and finish, rattles, corroding suspension components, difficult to buy replacement parts, etc.
If these companies were truly about making electric cars available to all, a partnership with a car company that knows how to do the "regular car stuff" makes a LOT more sense.
Instead you have these companies that might be innovative in the drive train, electronics, batteries, and co-packaging who have to learn all the "hard" stuff normal car companies have been doing for a 100-years.
Now, instead of moving into a partnership with a regular car company, they're becoming hardware/software organizations making custom silicon with custom software.
Even doing custom silicon and the associated software takes YEARS of expertise to do it and not have a 1000 warts, not withtsanding going into a MOVING VEHICLE where the risks of making mistakes is life and limb.
So, my conclusion is this is more fancy smoke and mirrors to impress investors and the general public, but not in the best interest of end-users (people who buy vehicles to use as transportation).
Wow, super hard disagree, comment here sounds like the typical arrogance hardware engineers face from people in software who've never really done the job or have some superficial experiences.
I won't blindly state "software is easier" but software is definitely easier to modify, iterate and fix, which is why sofware tools and resulting applications can evolve so fast.
I have done both HW & SW, routinely do so, and switch between deep hardware jobs and deep software so I'm qualified to speak.
If you're blinking a light or doing something with Bluetooth you can buy microcontrollers that have this capability and yes that hardware is simple.
But have you ever DESIGNED a microcontroller, let alone a modern processor or complex system ?
Getting something "simple" like a microcontroller to reliably start-up involves complex power sequencing, making sure an oscillator works, a phase-locked-loop that behaves correctly and that's just "to make a clock signal run at a frequency" we're not talking about implementing PCIe Gen5 or RDMA over 100Gbps Ethernet.
Hardware engineers definitely welcome better tools but the cost of using an unproven tool or tool that might have "a few" corner cases resulting in your $5-million SoC not working is a hard risk to tolerate, so sadly(and to our pain) we end up using proven but arcane infrastructure.
Software in contrast can evolve faster because you can "fix it in software". New tools can be readily tested, iterated on and deployed.
Yes... But in fairness I was just talking about the digital RTL, not the messy analogue stuff (PLLs, power/reset, etc.) I've never done that.
> but software is definitely easier to modify, iterate and fix,
Definitely true.
> which is why sofware tools and resulting applications can evolve so fast.
Not sure I agree here though. It seems to me that EDA tools evolve super slowly because a) hardware engineers are timid old fogies who never want to learn anything new, and b) the big three have a monopoly on tooling.
I read the write-up with a LOT of interest, this is really amazing work, there's not a lot of good options for auto-routing with open-source PCB tools (i.e. KiCad). I have also used the other autorouter you mentioned for "low-complexity" boards in KiCad and it helped do the job but was painful.
In my career I've also used the autorouter built into the "high-end" PCB tools and they could handle the complexity of boards you outlined WITHOUT needing a massive GPU, but they also paid people to improve this stuff over 15-to-20-years and development happened when single-core computers with limited RAM were the norm.
On the technical side, somewhat more recent FPGA 'placement' algorithms used a simulated annealing algorithm, while what you didn't isn't about placement, that approach could posisbly help with 'net cross-over reduction' type of passes, and maybe help with designs where you can do port swap / pin swap.
I'm amused you made a RISC-V array with discrete parts -- I'm sure you considered using an FPGA? Jan Gray has done > 1000+ RISC-V cores (https://fpga.org/grvi-phalanx/) in "older" Xilinx FPGAs.
If you're trying to emulate Thinking Machines / CM-x or anything else, frankly I think a "mondo" FPGA is still the way to go.
Job-wise: A suggestion might be to reach out to the guys at AllSpice ( allspice.io ) who make revision control software for Altium and possibly KiCad. The work you did to enable IPC, etc seems like exactly the type of skillset these guys might need (contractor, maybe full-time?) to interoperate with KiCad.
If I see anything that might be up your alley I'd also reach out. I'm not in a position to hire anyone and while "some companies" may not be impressed by what you did, the right organization WOULD be.
I share your sentiment that the likes of "modern" companies like Apple, MSFT, etc the hiring process is really taylored to "I want a guy who can do X" and rarely "I want a guy who's shown he can learn Y and Z so he can certainly do X".
> On the technical side, somewhat more recent FPGA 'placement' algorithms used a simulated annealing algorithm, while what you didn't isn't about placement, that approach could posisbly help with 'net cross-over reduction' type of passes, and maybe help with designs where you can do port swap / pin swap.
Yeah, that was the first step in creating the netlist for the backplane. Simulated annealing on the 8196 nets. TO BE FAIR, this would be a lot easier to route if I didn't explicitly want each of the 16 cards to be identical, but I think that's the most cost-effective way to do it.
As far as an FPGA.... I don't know if I see the point. The nodes in the original CM-1 were basically _only_ ALUs. Very little processing power. The CM-5 was a little better, but this entire thing is batshit crazy. I might as well go for four thousand individually programmable cores. Like, what even is a MISD computer? I have no idea, so lets build one. See what it can actually do.
If you're open to technical feedback your last comment, I've worked on these kinds of systems, have architected and built things even far "weirder" and these products have shipped and out in the real world, in silicon, in FPGAs and things between.
The reason an FPGA is a more suitable platform is you can translate "physical effort of making PCBs" into "creating a design in an infinitely re-programmable platform" and change your design as needed to your hearts content.
In fact, the original design of RISC-V included a bus called 'TileLink' to enable 'Many core' arrays of RISC-V processors.
Translation: You can pare-down open-source RISC-V cores and use TileLink and emulate CM or build something more complex as you see fit since that was built into the original open-source RISC-V specs.
FPGAs are their own joy and pain for sure and it's not as "cool" to re-program a blackbox on a PCB as it might be to make your own thing, so all depends on your goals.
I dunno. Each of these physical processors have 8 kilobytes SRAM and 62 kilobytes of some kind of flash or something. Multiply by 4096, wouldn't that be one hell of an FPGA?
I understand why someone might this this is a pay issue, but it's goes beyond that.
Culturually, doing something "well"(quality oriented, mindful of end-users) vs. "got it done" (transaction, pragmatic way of looking at things) is the heart of why outsourcing to many different geographical areas (India included) often results in something different than expected.
Also condemning every one in one part of the world as thinking one way is certainly not fair or true, but there are definitely unmistakable trends.
For example, most of the security portfolio that GCP provides is developed and product managed out of the Google Hyderabad office, as is a fairly major Israeli CNAPP product that starts with "A", a large CNAPP from a public Israeli-American security company that is directly positioned against Wiz, and a major security vuln mgmt and redteaming tool used by the DoD, GitHub, and Google. But all these employers pay $60k-130k TC for mid-career security professionals in India.
We scoop up anyone who is remotely competent at transnational firms or startups because we can afford to pay Western salaries, and traditional conglomerates in India largely do not care about web exploits unless they are a web platform first and foremost.
Tata Motors - being an automotive company - does not care about web development for the same reason GM doesn't as well: it isn't tangibly connected to revenue generation. As such, they will just contract it out to TCS (a Tata Group company, but both are independent of each other) at the lowest contract rate possible.
Cyber insurance or the threat of litigation after facing a severe breach will be the biggest driver for better security outcomes organizationally.
For example, both Zerodha and Razorpay have cyber insurance and PhonePe and Paytm both cleaned house after major incidents years ago.
It's also the same reason CapitalOne revamped security after the 2019 breach due to a misconfigured WAF.
Essentially, only the risk of either litigation or inability to secure cyber liability insurance will motivate Tata Motors to better manage security. And based on the JLR incident and their inability to secure sufficient cyber insurance, I think Tata Motors will clean house internally.
Everyone is saying it’s about pay, but India is a low trust country (so far as large datasets saying as much can be trusted). Anecdotally I have heard the same from my expat friends as well.
I’m not saying pay has no influence, but saying culture has no influence makes no sense. Even if it was all about pay, wealthy Indians choosing to horde their wealth instead of distribute it (caste system, etc) is a cultural root for the pay problem. The two are so intertwined that it’s impossible to claim it’s black and white.
The current western trend of outsourcing and/or importing labor is the real source of this issue. Western businesses care only for profit, so they employ cheap labor. Western culture is currently much more low trust than it was 50 years ago, and trending worse. If anything, I think culture is the more defining factor - pay is downstream of it.
Don't want to get into low quality generalizations in your post except to note tahta casual Google search will show you that Tata group is one of the most philantropically oriented groups. Which of course, doesn't excuse this issue.
Pay should reward doing something well vs merely doing something. Of course, this would generally mean you need to pay more than the competitor which will happily pay for merely doing something. So yes it is about pay.
Also, Indian companies are competing with American and Israeli founded or funded companies and startups for the same talent.
If you are competent, instead of earning $15k TC working for an automotive company, you could demand $40k-70k in TC from an MNC or a well funded startup (assuming you have the skills to back it up) - and those are the numbers my portfolio companies use to target hiring in India, as well as what I used previously before I became a VC.
Western companies have the exact same problem though; I've dealt with plenty of incompetent people there too because the organization does not reward technical excellence and quality, so it is completely pragmatic for employees to focus their time on the things that are rewarded (engaging in politics, etc) instead.
During the startup/ZIRP era there might have been people doing the "right" thing because they had skin in the game thanks to stock options or they were paid just so fucking much that they didn't care about putting in the extra work. But as total comps go downward (coupled with inflation) the output's quality tends to regress to the minimum acceptable.
> I've dealt with plenty of incompetent people there too because the organization does not reward technical excellence and quality
Organizational dysfunction transcends all boundaries, but to a certain extent the kind of issues that lead to the kind of incident such as the one above happen because the affected product (e-Dukaan) is viewed as a cost center by Tata Motors.
Sadly, in most cases, a lot of security will always be viewed as a cost center and never prioritized unless forced to due to insurance, audit, or regulatory pressure.
That said, a thesis I've had for a couple years now is that if we can successfully shift-left by turning security into a DevTool problem as well as an organizational problem, we can both reduce remediation time as well as build stickiness for security products. The AppSec category has definetly adopted this kind of mindset.
I think it's super cool that you work at Canva and are taking the time to interact with your customer base.
Maybe this isn't the right venue (I didn't see an e-mail address in your profile so I'm just asking here) but can you pass along feedback to the UI team for Affinity?
I personally think most programs, especially audio / video editors are improved by:
A) Optionally having icons that have text labels in-addition to the image (i.e. the word "Cut" + scissors, "Paste" + paintbucket, etc) ; doesn't have to be full on MSFT 'Ribbon' UI either!
B) Giving users the ability to choose how big or small the icons (and associated text) are (i.e. 16-pix, 32-pix, 64-pix or small, medium, large)
For point A:
I am aware this creates a challenge when you make a release of a program for other languages, so it's a burden on the translation and software validation teams.
Use-case: I work between so many different programs when doing photo editing and learning the pictogram icons for each application is mentally burdensome that it's VERY helpful having labels as well. Otherwise I constantly find myself hovering on an icon and reading the tooltip, that text might as well be integrated into the icon!
I end up using CaptureOne for image processing, DxO for noise reduction, Affinity for pixel editing and that's just in dealing with RAW photos for one type of photography, I might use others as well depending on the subject matter.
For point B:
Our monitors now are super high DPI and squinting at tiny icons designed when we had limited real-estate is a real tax on the eyes.
Thank you again for reply on this public forum and many us who are paying customers are happier to give you guys money over companies like Adobe who now only offer subscription software.
All of the public money spent on going to the moon is really just a way to funnel $$ to a few sub-contractors the actual science value of going BACK to the moon is pretty low.
It takes such a huge amount of people time, effort, resources AND has an environmental impact to launch a payload into space, we should be expending these resources to help solve our societal/environmental issues, not for "showboat science".
reply