SoylentNews is people
SoylentNews
Arthur T Knackerbracket has processed the following story:
Electric vehicles may become a new front in America's tech war with China after a US senator called for Washington DC to block Chinese-made EVs to protect domestic industries and national security.
Sherrod Brown, senator for Ohio and chair of the Senate Banking Committee, penned a letter to President Biden, claiming "there are currently no Chinese EVs for sale in the United States, and we must keep it that way."
He warned that "Chinese EVs, highly subsidized by the Chinese government, could decimate our domestic automakers, harm American workers, and give China access to sensitive personal data," insisting the US government must ban Chinese-made EVs as soon as possible, calling it "a matter of economic and national security."
The move comes as the dispute between the two economic superpowers over technology rumbles on, with the US last week sanctioning four more Chinese companies, claiming they were involved with providing chips for accelerating AI to China's military and intelligence users.
Among those added to the Entity List maintained by the US Department of Commerce was Sitonholy (Tianjin) Co, understood to be one of the largest distribution channels for Nvidia's datacenter products in China, thus cutting off supplies of Nvidia GPUs to many Chinese companies.
[...] The number of Chinese cars purchased by US customers is understood to be very low as these are subject to an extra 25 percent tariff on top of the regular 2.5 percent import duty that DC applies to imported vehicles.
However, Senator Brown notes in his letter that BYD already sells an electric hatchback named the "Seagull" for the equivalent of less than $10,000. This compares with the $28,140 that has been reported as the starting price of the current cheapest electric car available in the US, the 2024 Nissan LEAF S.
There is also a national security twist as Senator Brown claims that data collected by the sensors and cameras in Chinese EVs could pose a threat. "China does not allow American-made electric vehicles near their official buildings. To allow their vehicles freedom to travel throughout the United States would be foolish and highly dangerous," he stated.
Senator Brown also claims in his letter that nearly 20 percent of all electric vehicles sold in Europe during 2023 were made in China, citing this as a cautionary example.
The European Commission last year announced an investigation into subsidies in the Chinese EV industry, but there are said to be misgivings in Germany and elsewhere that a ban on Chinese EVs could backfire, with Beijing retaliating by locking Western carmakers out of the lucrative China market entirely.
(Score: 2) by JoeMerchant on Thursday April 18, @01:18AM (2 children)
Oh, and while we are here, every software module in the system should be OTA updatable, but only when a physical switch is set in the "updates enabled" position and another physical switch, momentary type, enables the update to start.
Cyber security is good, but why don't we have a layer of physical security to go with it?
🌻🌻 [google.com]
(Score: 2) by bzipitidoo on Friday April 19, @02:16AM (1 child)
I have great-great grandfathers on both sides of the Civil War. I like to think the Confederate one wasn't that committed to upholding slavery. He deserted near the end, and who knows, maybe had little choice about joining in the first place and was merely waiting until the odds of getting away with deserting were good. The retreat towards Appomattox would have provided many excellent opportunities to slip away, while moving him closer and closer to his home in the Piedmont in North Carolina. But yeah, good point that the pain of ripping up trade ties often isn't enough to stop violence loving idiots from starting a war.
One of the curious things about current computing capability is how much these devices that are so fantastic at automating things are themselves strangely difficult to automate. Suppose you want to send keystrokes or mouse clicks to an app, without having to physically work a keyboard and mouse by hand? Where is the app to deliver keystrokes? Not included in the OS! Or, can't a second computer be plugged into a USB port and simulate a keyboard? Or, why can't all apps have something like the GIMP's batch mode? Sure, these things can be done, but for most users tools to do that are out of sight and out of mind. About the only thing that's fairly common is a macro keyboard. But much online gaming depends on the players not using such things, and the vendors will go so far as to ban players who do. One time I wanted to capture keystrokes to help with debugging a problem, and all I could find was key loggers for recording passwords, as if that's the only use of such a thing. I guess one reason such tools are not readily available and easy to access is that they make a lot of current security practices much less secure.
But I think a bigger reason for the feeble self automation capabilities of computers is the same as why there aren't more standardized and open products.
(Score: 2) by JoeMerchant on Friday April 19, @12:43PM
>Where is the app to deliver keystrokes?
Google AI says "AutoKey" - but I have been using xdotool for decades.
>Or, can't a second computer be plugged into a USB port and simulate a keyboard?
Ethernet is more conventional, but I think you can make ssh work via USB if you read a few HOWTO guides.
>why can't all apps have something like the GIMP's batch mode?
For the past 10 or so years, I have been working "behind the scenes" on a device that presents a .net GUI in Windoze/VirtualBox over Ubuntu. I have been developing a suite of apps that run in Ubuntu (poor man's multi-threading: each app is single threaded, if you've got a process that blocks too much: give it it's own app - yes, it's more resource intensive than threads, but somehow all this wasteful multi-app work still barely touches 10% of any given resource on the system at peak, less than 1% most of the time) - these apps are written in Qt and have their own GUIs that are only used by developers and testers to see what's going on in the individual functions they implement. At their core is the "QProcess::start("xyz")" call, where xyz is what you would normally type into a terminal. Doing things this way, I'm taking complex terminal commands with options and parameters and making them very systematic: click this button and the right form of the xyz command will be executed, with all its complicated options and parameters exactly the same way every time. Batch mode.
>for most users tools to do that are out of sight and out of mind.
And that's the point. Users don't want to open the printers dialog and re-select a new default printer after plugging in a new model, before printing their next report, so the "out of sight, out of mind" apps do things like that for them, resuming the print queue when it stalls, etc. Linux desktops (Gnome, KDE, et al) do a lot of this, but our product focuses on a small subset of desktop features and automates them for our users in their limited workflows.
>the only thing that's fairly common is a macro keyboard.
Typing on one now, I believe the form factor is called 60% - no dedicated F keys, I reprogrammed home to be end, fn1-esc to be ` and fn2-esc to be ~, and I have a fn1-N macro that does a cd into my normal working folder. Then I forgot how to program macros and haven't tinkered with it for years. I also have a very programmable "gaming mouse" that I got because it's got a nice feel and response - never touched its programmable functions at all. Too many brain cycles for too little return.
>the feeble self automation capabilities of computers
The features are actually there, and that's what makes them dangerous. Most people are unaware of the possibility - even those who are aware when you ask them to think about it don't consider it as a normal part of daily operations - out of sight, out of mind. That's why I feel like the "big RED physical switch" would be such an improvement for cybersecurity. All these touch-screen based "Are you sure?" prompts can be bypassed a thousand ways with "living off the land" tools. If you are running secure code, part of that security certification would be a requirement to throw the enable switch to enabled position and then to press the "initiate" button. Physically, those interfaces should be through the simplest possible paths into the microprocessors: debounced with RC circuits, ESD/EMI protected with passives, and otherwise direct wired into the same chip that will be handling the software update. The update code should start with a very clear unambiguous test of those two physical components before proceeding - kind of like the two keys required to launch an ICBM.
Yes, we should have a "patch Tuesday" that regularly ships updates for everything, and people should be applying them in a timely fashion. However, the updates should not be able to propagate like a worm to all the systems in the world without human intervention. Back in the '80s I came up with a "scheme for world domination" and the whole key to it was an "innocent" feature in network (BBS at the time) connected software: the ability to update the software, loading arbitrary code. There's no way around allowing the loading of arbitrary code if you're going to allow patching any possible vulnerability discovered in the future, but you can at least prevent the arbitrary code from spreading itself without human intervention.
🌻🌻 [google.com]