So it’s an overpriced middle of the road phone to signal ones devotion to Trump and doesn’t actually deliver on several of its core promises (like made in USA).
Just to be accurate, they don't say that it's made in the USA. They only say its assembled in the USA. Perhaps in the past they made some statement that it would have been, but the current box and marketing don't.
Yeah they updated it way late in the game when they couldn’t hide it anymore, well after money had exchanged hands. That certainly qualifies as a broken promise.
Last i read most of the money came from people not reading the fine print on their $100 deposit and only a few thousand have actually been distributed.
Looking now I see maybe tens of thousands of open orders still
I don’t want to get bogged down in a source dispute - this is very easy to search and/but I only spent about 60s on it. I am hardly an expert. Feel free to look it up as well and tell me how I am entirely wrong. This was a combination of AI responses + thumbing through the sources linked to make sure it wasn’t invented whole cloth.
I do not think they are selling well. That seems to be the consensus here.
I don't think they are selling well, either. I was wondering at your source since it would be very atypical for any company to give any numbers at all, let alone a company that's so outwardly sketchy, let alone numbers like "This is the number of orders we have standing open despite being actively in production." This is the exact kind of thing I would not expect to be easy to search, and it'd be ripe for AI hallucination.
The only numbers I can find in a quick search of my own are the leaked numbers stating 30,000 orders placed from 10,000 customers, with nothing said about shipped orders.
I much prefer Bryson City to Gatlinburg, and you can technically go into the park right outside Bryson City at Deep Creek, and even hike to Clingmans dome.
Gatlinburg is a tourist madhouse while Bryson City is a great little town and you can drive over to Cherokee if you want more and get into the main part of the park and over to Gatlinburg should you so desire.
Road to nowhere is always fun to visit, kids always laugh at the graffiti and like the creepy tunnel while the hikes around are beautiful.
Wonder if they will ever fix upload progress using XHR, pretty annoying to not be able show accurate progress to the user when using larger chunk sizes:
MSSQL can handle 32k open connections no need to run a pooler in front of it, can PG do 32k connections and a process for each?
MSSQL shares cached query plans between connections including jitted code, PG cannot do that and the changes needed to make the plans cross process portable would be extensive while sharing between threads is just normal code sharing between threads.
Interesting I have definitely used the distinction between null and empty string quite a bit in MSSQL and matches most programming languages.
Another issue that used to exist was Oracle table name were limited to like 12 characters or something so I have seen horrible abbreviated table names to fit in the Oracle limitation even in other DB's due to some systems being able to run on both MSSQL and Oracle even though SQL Server has a 255 char limit for table names.
Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection which has a max of 32k per instance.
There are no need for connection poolers in front of MSSQL although it is normal to pool connections in the client application which may hold hundreds open typically in a web server.
This also allows MSSQL to more easily share cached query plans between connections since its just sharing executable code between threads.
For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way.
PG has it obvious unix roots using processes instead of threads, MSSQL coming from Windows where new process are expensive and there was no real fork, but threads are cheap uses that approach instead.
>> Each PG connection being a whole process does not scale like MSSQL that uses a thread per connection
There's no free lunch id think, the PG model is more robust. Unsafe extensions can take down the whole instance in the threaded model, processes contain the blast radius to that connection (also typically easier to debug since this type of issue is thankfully rare, it's also gnarly to get on top of).
Further, on linux (not on windows) a lot of the lines between a thread and a process get blurry (copy on write, shared memory mappings etc). They're both handled very similarly in the kernel, theyre both scheduled using similar machinery.
>> For PG to do plan caching it would need to serialize the plan between processes and that would require some significant work since it was never designed that way.
Is that true? I'm thinking the buffer cache and locks and WAL coordination are just as fast - it's just mmap'd SHM into each process. It's not like every access needs IPC?
>Unsafe extensions can take down the whole instance in the threaded model, processes contain the blast radius to that connection.
MSSQL has its own task scheduler with the ability to kill etc, its like its own OS internally in that respect but yes there is no memory protection there for unmanaged code.
It doesn't really have unsafe extensions other than it is possible to create extended stored procedures which could do bad things, very frowned upon. If you were concerned about that you would run that database in its own instance (process).
>I'm thinking the buffer cache and locks and WAL coordination are just as fast - it's just mmap'd SHM into each process.
Plan caches contain pointers to executable code and sometimes jitted code, this cannot be just shared to another process with a different address space and work, this is code not data, to transport between processes it needs to be serialized in a way that is not tied to process memory including things like ASR, certainly doable but since it wasn't designed that way much needs to be changed vs just sharing between threads.
I don't agree, a relational database is not required to have a particular storage engine or format, that is an implementation detail.
There are other relational databases that have both kinds of storage engines and some use both on the same table (row based insert with column based migration and secondary column store indexes: https://learn.microsoft.com/en-us/sql/relational-databases/i...
Just like you can have b-tree based table storage vs heap in the case of index organized tables / clustered indexes (which pg doesn't have) you can choose column based instead the logical data model is still the same relational model.
Why does the FSD blindly accept accelerator input in the face of a dead end cul de sac with much lower speed limit? Is this some sort of regulation?
I have driven normal cars that cut power and brake if they detect a perceived dangerous situation usually annoyingly and in error. Traction control will also cut power to prevent wheel slip regardless of pedal position.
I say the machine should always be easily overridable, and the human always held responsible for the consequences of their operation of their machine. If you're driving a normal car, and you get in an accident, and the accident is your fault and not the fault of another driver, then it's you that pays the price of that accident one way or another. If the machine has some sort of "brain" like "full self-driving" or "driver assist", then that should be easily and instantly overridable and the human should always stay at least as aware of their surroundings as they would in a standard more traditional non-self-driving car and always be on the ready to take over control of the machine at a moment's notice. Same thing as with old-school "cruise control". You still gotta be ready to speed up or slow down under manual control, and / or disengage cruise mode entirely if necessary. No different for FSD IMHO.
FSD is obviously very different than normal cruise control and I cannot see an argument why a system that knows its heading down a dead end street at more than double the posted speed limit would allow such and accelerator override and not apply automatic emergency braking, it makes no sense, that serves no purpose while leading to a tragic outcome.
FSD has Automatic Emergency Braking but that does not apply to hard acceleration by the driver, which is an explicit UI to take control from the autopilot.
you don't want your car to refuse to move when you are stuck on a railroad crossing despite the gate in front of the car being down. there must always be a way to override the autopilot.
Moving off a railroad track at what maybe 15mph max is very different than doing 70mph down a cut de sac double the posted speed limit. I am not saying FSD should prevent any forward movement, how fast can it go in reverse? Probably something like that.
yes, but according to the car you'd be crashing right into a barrier no matter the speed. the car needs to ignore that and allow you to break the barrier.
The design philosophy is that this is driver assistance where the driver is the supervisor, rather than the car supervising the driver. Sustained acceleration is interpreted as the driver overriding the car. For unsupervised autonomy in the Cybercab they remove the ambiguity by removing the accelerator pedal.
I guess that seems ridiculous to me. I could understand if its some sort of government regulation, but if you want to ram a house or anything else or go double the posted speed limit then you should be required to disengaged FSD and go manual, obviously.
There are plenty of videos of stuck vehicles that have a hard time due to traction control disallowing power even with full accelerator pedal, this is not a foreign concept in a modern vehicle. Here is one example, they refer to traction control as the soup nazi, no power for you! : https://www.youtube.com/watch?v=WLVae7-N_Vs
It's a feature to look for in a off road vehicle if it has a traction control disable and even ABS disable on motorcycles, this is an explicit command to disable a safety feature that typically resets when power cycled. Not sure why FSD would allow overriding an obviously unsafe situation, the operator can disable the whole thing at any time if they wish to do so and go manual with a specific on screen command rather than hitting a pedal right next to the other stop pedal with your foot resting between them otherwise.
So my understanding is the telemetry shows the FSD was on and driver held the accelerator down the whole time and the car did 70+ mph into the home.
Tesla proponents say it’s the drivers fault since the accelerator was held while dissenters say why didn’t the FSD step in.
I happened to just test drive a new model Y having never done so before and not being very interested for various reasons. I may be getting the new L version when released soon in the US it was very impressive especially for the current price compared to the competition and how impressive FSD was is part of my change of heart.
You can hold the accelerator while FSD is engaged to tell it to go faster, this made sense but I assumed it was a suggestion not a go down with the ship command.
So the question is should FSD prevent unsafe speed and ramming objects when engaged even if operator holds accelerator. Based on what I saw with FSD it should know the speed limit and that it was heading to a dead end cul de sac ahead of time and the cameras should see the house near the end perhaps too late to stop but at least slow down.
The argument is I have heard there are actually regulations requiring it to accept accelerator input regardless but I have used other vehicles that emergency brake based on sensor input while manually driving even somewhat annoyingly when no actual obstruction exists (phantom braking).
My thoughts are FSD was on so the accelerator is a suggestion not a to the death command and it should have not allowed the vehicle to enter the house at 70 mph. So while the driver is at fault so is FSD and the complacency it presents contributes to driver error.
Most likely explanation is the driver panic hit the accelerator instead of brake. From driving with FSD it seem easy to get complacent and then do something like that when needing to take over vs normal driving where you are already engaged with braking and accelerating manually.
> the telemetry shows the FSD was on and driver held the accelerator down the whole time and the car did 70+ mph into the home
We don't know what the telemetry shows. Tesla tweeted something. The driver says something else. That's insufficient data with which to conclude anything with confidence.
That is the current public information if it is true is only the driver at fault?
What are the alternatives? FSD on and no driver input? FSD off and driver rammed house without assistance?
This is mostly a thought experiment for me provoked by the incident after being impressed to buy one.
Tesla obviously wants to blame driver to absolve themselves while it’s obvious to me driving with FSD is not the same as driving normally when it comes to reacting to unusual circumstances and a certain amount of responsibility is given to the FSD.
Based discussion with the younger owners of FSD it’s obvious driving around manually will be like driving stick shift soon or writing in cursive, an atrophied skill that the younger generation will have no use for.
