Is it just me or do those angles deliberately obscure how thick it is lens-wise? I have a pair of X-real airs, 2 years old now, and they're pretty thick. They're 1/4th the price and basically work as a head-mounted display. Is that what this, but way fancier and more sleek?
> Some 57% of US doctors received more than $12bn in payments related to medical drugs or devices from manufacturers between 2013 and 2022, an analysis has found.1 “Despite evidence that financial conflicts of interest may influence physician prescribing and may damage patients’ trust in medical professionals, such payments remain pervasive,” says the letter in JAMA.
And the city wonders why I don't want to put my credit card info in their crappy parking app and would instead prefer to put a quarter into the meter for 30 mins.
In 2026, having my credit card number compromised is the least of my worries. At least here there is an established process for denying charges and ordering a new card. As long as you're not using a debit card, this is not a big deal.
Only time I've seen that is the stupid holds that hotels do for deposits. The time I had the bank correct a debit card issue had the money available immediately. The only real hold on the account was waiting for the new card to arrive, but the funds were available
Most people have a line of credit far larger than their actual use. With a debit card that's coming right out of your account, which means your mortgage, if it comes in before you notice the issue, is going to then fail.
This is also partially that people don't put critical bills on their credit card typically. And even if your credit card does get maxed out, you typically would have a second credit card handy. But those credit card payments have to come out of your bank account and so you're risking that you intend to pay your credit card you said Set whatever it is to send the money in but there's no money in your account And so it doesn't get paid and now you have late fees on other accounts
If your debit card is going to a different bank than what you normally pay all your bills out of, this is not a worry. That is not how most people I know handle their banking though, which is why it is a real problem to worry about.
> This is also partially that people don't put critical bills on their credit card typically
This is probably atypical, as the average people I know put their critical bills on their main credit card that they use everywhere:
I put my autopay bills on a credit card that sits in my safe. The only reason it would see a fraudulent charge is if one of the few companies that has the card information, is hacked. And that actually happened once.
My bank just removes the charge if I say it is fraudulent. If I dispute a charge (I made a purchase but the other end didn't hold up their end), then my bank gives me a credit until the dispute is resolved.
Perhaps not everyone has a good credit card and/or bank though, idk.
Meh, I’ve been giving out my credit card number willy nilly to merchants for 20+ years, and it hasn’t been used without my authorization over the course of what must be tens of thousands of transactions.
I have a text alert setup for transactions, so I presume I’d be able to successfully challenge any fraudulent ones pretty quickly.
Me too. Interestingly my card has only been fraudulently used after I gave it to a waiter at a high-end restaurant, and at a gas pump in a small town that didn't have tap-to-pay.
In USA, folks who check their statements monthly are at little risk of immediate financial pain there.
When your lifetime of credit card transactions leaks, that could be financially painful, embarrassing, etc. (can be discriminated against, including with pricing)
I do dislike creating a log of where I park on some random company’s server. Nice that ALPRs/govt.-funded corp spycams/Ring/etc. make sure the quarter method is minimally marginally effective at protecting privacy.
who stores card numbers other than the processors? that should be a hangable offense. I've integrated card processing on multiple sites, and not once does the form come from me. I add the processor's JS, and it collects the data to move along. They then return to me a bit of information that includes success/fail so that I can decide what to do from there.
Yea, it's insane seeing this person arguing about the nature of credit card theft when we have a million different examples of how it happens and how rarely the end user knows until it's far too late. We almost always learn about itpost ad hoc.
You've moved the goal posts. A typical site isn't storing the numbers so when they get hacked, that data is not available. If you're suggesting hackers directly injecting malicious JS to hijack card data then that's totally different. I'm not insane about this particular subject. You're just standing on a soapbox
Parent is right. Use of uninitialized memory is UB, and incidentally, the type of UB that the C standard is not working to define, but is relying on sanitizers to find in source programs, since it is considered always a bug.
This entire thread has a lot of "no security issues have ever been found in my code, and I test a lot. Therefore no bugs will ever exist in my code and we're all safe." To see you doing this in an explicitly security-conscious setting is distressing.
If anything, I see assertions like this and juxtaposed with blatant, willful misunderstanding of how C and C compilers work and it does the opposite of inspiring confidence.
Look at CVE-2009-1897; this is the classic example of how C compilers are happy to try to optimize code in the face of UB and lead to worse problems.
> If the above code has any but one of the above 16 outputs
I don't think you understand how insane optimizations in the face of UB can be. Just go look at this issue:
>>>no security issues have ever been found in my code, and I test a lot. Therefore no bugs will ever exist in my code and we're all safe<<<
That’s not what I have said. 35 issues (mostly minor, but a couple of remote denial of service attacks) have been found with my code in the last 25 years; of those, none have come from the PRNG code I used. Here in the age of AI, I get multiple security reports a year, so the code is being looked at.
With crypto, you can never know for sure the code doesn’t have weaknesses, but one can have confidence in code and algorithms which have been around for years without any weaknesses discovered in them.
My question is: If code being around for years doesn’t build confidence in it being secure, what would it take to build confidence in the code.
What you’re seeing here is two schools of thought: One is the issue with using uninitialized memory, which yes does result in undefined behavior as per the C99 spec—but, back two decades ago when I made that decision, GCC was the only compiler of significance (clang was just released but was not widely used until years later) and its behavior was to put randomish data in undefined allocated memory.
The other is the notion that only Linux Kernel developers can develop a secure PRNG, and obviously I find that attitude very condescending and arrogant.
> My question is: If code being around for years doesn’t build confidence in it being secure, what would it take to build confidence in the code.
One of my experiences with programmers is that we (and I do not exclude myself from this category) are extraordinarily bad at sufficiently imagining the failure paths that our code might take and making code work handle failure cases correctly. It's these erroneous failure paths that are the real issue with code, and age doesn't really indicate how much testing of those failure paths actually exist.
To build confidence in code, what we need is proactive testing of potential failure paths that don't rely on humans to think of them in the first place--that means investment in various exhaustive testing techniques. (And I'd also like to see formal verification be more of a thing, but the tech just isn't there.) A stepping stone in that regard is also heavy use of static and dynamic analyzers to catch things that at known to be Obviously Bad™. The gold standard here really is whitebox concolic execution that's specifically trying to get something akin to 100% path coverage by trying to synthesize inputs to test the unhit paths.
Saying that it's okay to seed an entropy pool with uninitialized memory in 2005 is maybe defensible. There is a shift in compiler design around that time from thinking of it as compiling to a set of instructions and then optimizing them (so that the basic 'structure' of the code is something that's inherent to the program) towards looking at program semantics as abstract things where the only thing you need to preserve are the observable semantics [1]. One of the side effects of that shift is that undefined behavior stops being something that is fairly reliable so you assume you get the 'equivalent' assembly effects for that machine and starts being something that really screws over code.
But it's not 2005; it's 2026, and this change in compilers has been heavily advertised, discussed, complained about for well over a decade. And if you're using the kind of tools that give me confidence in code, those tools would have been bitching about that behavior for decades. If this is a surprise to you in this time and age, then it suggests to me that you've not really been proactive in trying to test your code in the manner I suggest, or worse, you have been proactive and decided to ignore everything telling you your practices are wrong because you know better than the tools and your code isn't obviously wrong.
(I say obviously wrong because your code example does demonstrate, when I tried it in the latest version of clang on godbolt, that it is eliminating the seeding of the entropy pool, in a way that is actually pretty clear if you read the assembly.)
[1] One of the most concrete examples to really observe the difference is the concept of control flow. Compilers nowadays are really happy to turn control flow (if statements) into dataflow (conditional moves or funky bit manipulations) and vice versa, because the only thing that needs to be preserved is the final value. Of course, cryptographers keep complaining that we broke their code by turning their obfuscated dataflow-based if statement into an actual if statement and so it's no longer constant-time, no matter how many times we keep telling them that we do not make any pretense of guaranteeing constant-time execution of code.
>>>we (and I do not exclude myself from this category) are extraordinarily bad at sufficiently imagining the failure paths that our code might take and making code work handle failure cases correctly<<<
The way I somewhat work around this with the newer coLunacyDNS code (from 2020) is by using `-DGCOV` and `gcov` to check the code coverage when running the automated SQA tests for the code. I can’t cover every single failure that could be caused by sanity tests in the C code, but I can cover pretty much all (99.53%) other code.
>>>But it's not 2005; it's 2026, and this change in compilers has been heavily advertised, discussed, complained about for well over a decade.<<<
My code compiles to the C99 standard (-std=c99 and only two syscalls not defined in POSIX) [1]. This in mind, compiler makers have a responsibility to make sure that their compilers, no matter what changes they introduce to them, conform to the C99 spec when compiling with the -std=c99 flag. [2]
This means that when I interact with people working on compilers, I bring out the C99 spec and then use that to determine whether it’s a bug in my code or a bug with the compiler. In this particular case, the C99 spec said it results in undefined behavior when “The value of the object allocated by the malloc function is used”, so that’s a bug with my code.
The thing about standards is this: A given piece of C code, if standards compliant, should, when compiled, act a given way with any compiler conformant with that standard. C developers writing C99 code shouldn’t have to look at any development or document which exists after 1999 to determine whether their code will act a given way. C compiler writers shouldn’t be telling C99 developers “well, you should know about this 2021 change to the C compiler”. They should instead say, “well, if you look at this page of the C99 spec, that behavior is undefined so we have no obligation to implement it the same way GCC does”.
Standards correct C99 code written in 2005 should behave the same way when compiled in 2026 as it did in 2005.
This discussion is like the fights guys get into when playing wargames where they argue whether a given move in the game is legal or not. When this happens, the correct thing to do is to look at the reference manual and see what that says.
>>>it's okay to seed an entropy pool with uninitialized memory in 2005 is maybe defensible<<<
Back when I made that decision, clock_gettime() was not universally implemented (it wasn’t implemented on MacOS), so my options for having some kind of entropy for the XOF should /dev/urandom have issues were very limited. I’ve since updated the code to use clock_gettime(); the Windows port will instead use the non-portable GetSystemTimeAsFileTime() (ghosts of embrace/extend/extinguish). [3]
>>>cryptographers keep complaining that we broke their code by turning their obfuscated dataflow-based if statement into an actual if statement<<<
The cryptography I use, as is typical for post-AES cryptography, makes sure that the cryptographic core doesn’t use any control flow statements, as seen in this compact representation of that code: [4]
[1] The code also assumes that /dev/urandom returns a random stream of bytes, a behavior which POSIX doesn’t specify (newer POSIX finally gives us randomness with getentropy() but that spec is too new for me to assume it’s widely implemented)
[2] Until about two years ago, -std=c99 wasn’t needed; C99 code happily compiled as recently as 2022.
[3] Let me make this crystal clear: I use both /dev/urandom and looking at jitter with clock_gettime() in the entropy pool my XOF PRNG uses. Should one of those not have enough entropy, the PRNG is still as secure as the other source of entropy.
[4] I very rigorously made sure that k>>j%32|k<<-j%32 trick works to do a bit rotate while being C99 standards compliant because clang broke an earlier version of this bit rotate at some optimization values; note that j and k are uint32_t variables. Looking at the relevant parts of the standards show this trick only works when the modulo is a power of 2.
The production code either uses x>>r|x<<(32-r)%32 or this:
r = ((i * (i + 1)) / 2) % DWR_WORDSIZE;
// Other code not shown
if(r > 0 && r < DWR_WORDSIZE) {
A[i] = (x >> r) | (x << (DWR_WORDSIZE - r));
} else {
A[i] = x;
}
The “if” isn’t a security issue because r has a predictable value which we assume the attacker already knows.
> The thing about standards is this: A given piece of C code, if standards compliant, should, when compiled, act a given way with any compiler conformant with that standard. C developers writing C99 code shouldn’t have to look at any development or document which exists after 1999 to determine whether their code will act a given way. C compiler writers shouldn’t be telling C99 developers “well, you should know about this 2021 change to the C compiler”. They should instead say, “well, if you look at this page of the C99 spec, that behavior is undefined so we have no obligation to implement it the same way GCC does”.
The thing about standards is this: we have the same ability to write large, bug-free specifications as we do to write large, bug-free applications--effectively none. Bugs in the specification can take years or even decades to be discovered, and then the interpretation adjudicated and fixed in a newer version of the standard, with the fossil C99 specification never being updated or given any indication that the original text was buggy. On top of that, compilers don't implement C99, they implement C99-with-compiler-extensions, and those compiler extensions' documentation range from poor to atrocious.
> Standards correct C99 code written in 2005 should behave the same way when compiled in 2026 as it did in 2005.
Standards-correct code means not hitting UB. The number of programs that exhibit UB is approximately 100%, especially in 2005 (which is about when GCC started optimizing based on C's effective type rules). The best way to figure out whether or not your code is standards-correct generally isn't to read the standard [1]. Instead, go run a suite of undefined behavior sanitizers on your code to see if your code is known to violate some of the rules. We unfortunately don't have checkers for all the known UBs (for example, effective type rules).
[1] The standard is hard to read, especially because you have to know where to track down more authoritative sources to be able to resolve interpretation issues. I'll note that you've both incorrectly identified the source of undefined behavior and incorrectly identified where to find the undefined behavior--you're citing Annex J, which is an informative section, meaning it doesn't actually mean anything as far as interpretation goes (and I'm aware of at least one entry in there which is outright incorrect).
I honestly do not understand what the 28GB Tahoe update contained. Like, I cannot imagine what all the code does. It'd take a lifetime to actually go through it all, and yet, here I am just using the same programs I did before it, just with rounder corners and some other pretty things. Actually wait, fewer programs, because some things break or have markedly less functionality.
>> Actually wait, fewer programs, because some things break or have markedly less functionality.
The new liquid glass ui also fails a lot of basic accessibility checkpoints like contrast, readability, and increases cognitive load.
The rounded corners you speak of also hamper tap and touch targets for users with motor disabilities. The rounded corners make icons and other elements less distinct, increasing the possibility of touch or tap errors.
The blur effect from liquid glass slightly, but noticeably, lowers the frame rate on iOS 27, as well. By turning on "Reduce Transparency" it became a bit smoother, more like iOS 18 was. God I miss iOS 18.
First thing I did was turn on reduce transparency - even on iOS 18. And Reduce Motion. I also disable high frame rate and keep it at the lower option of (I believe) 60hz.
Used to do the same on Android plus more (you can disable most animations in developer)
Also highly recommend going in Accessibility on iOS and changing the screen swipe or slide effect or whatever. Results in much faster transitions. And all of this has always seemed to keep the phone cooler and battery life working longer.
If you want to get deeper disable all widgets completely (delete everything off the far left Home Screen). Disable weather auto updating based on location (if you deny it access to location then the Apple Weather app can just be set manually to track specific zip codes or cities).
I also do not get the insane folder thing everyone has on their Home Screen - I delete them all immediately along with all icons and keep one completely blank homescreen (with a cool background) and 4 things on the dock. Then only one other Home Screen with just a few additional icons in the corner. If you need any other app just search or go to the screen far right App Library !
The folders were useful to me for years, aided by the macOS iTunes feature to view and rearrange things via drag-and-drop. Still annoyed that feature was removed.
I don't take this abuse any longer. My last Mac is on macOS 14 and it will stay there for the remainder of its existence. I'm on Linux now and I'm not missing much compared to Mac. I'll put it this way: If a move to Apple Silicon would make me lose most of my apps anyway, then I might just as well move to an OS where I'm the boss again. Also, gaming got way better with Steam's Proton and the Heroic Game Launcher for GOG and others. I'm not going back.
Many apps in the App Store are now 0.5Gb in size. I got an M5 with 2 Terabytes a couple weeks ago and I was wondering why do I need all this space for. I guess I might end up short on space.
The way things look, everyone in Trump's orbit is just grifting off the government directly or using it to their personal advantage, including his own children. He literally said "Every time my kids invest in a stock, they have inside information."
Ok but why "find me a book that explains how car insurance works" no find book that explains how car insurance works but find exactly one car insurance company?
> every other modern app tries to claw your eyes out.
They do, and it's annoying that even apps for "real work" do the same thing by flashing notifications/tips in your face, advertising a new feature you don't want to use right now, or warning you that everything is about to break soon.
I worked at Sun labs and used a Sun Ray daily for a whole summer. It worked...OK. Definitely not "Incredibly well". We had a network of a few hundred Sun Rays and two E10Ks backing it. More than a million for the servers and $1000k a piece for the Sun Rays was not cheap. Basically any $1000 laptop was more powerful, without the need for a crazy powerful Sun server. The experience of taking out my ID card, walking down the hall to another cubicle and popping it in and getting my session was magical. But I did that less than once a week, so I don't think it was overall worth it. The Sun Rays also had a pretty crappy LCD, about 1-2 years behind the SoTA.
It was a cool idea. It will keep coming back again and again. But at Sun's price points around the early 2000s, it was a loser, and I actually agree with the market in this instance. Sun Ray was a flop.
The "two E10Ks" part is the important part there, as you need a very powerful server to support SunRay users running Solaris. At my university there was something like 200 SunRays supported by cluster of T2000s (7 nodes IIRC), it was fine for CDE, Firefox and few dtterms, completely unusable with Gnome (it took Gnome like 10 minutes to even start).
On the other hand I have heard of some success stories about using SunRays as RDP clients, which is actually supported configuration (you still need a Solaris box that manages the sunrays and translates RDP to ALP).
Citrix is still everywhere you need a client that can do things a web browser can’t—like run ancient VB4 software or talk to device hardware—deployed at scale.
Citrix was bought out by PE for $16.5B a few years ago, under the (sadly correct) assumption they hadn’t been charging their customers enough money for this essential tech.
GeForce is pretty successful. But only because Nvidia can sell itself GPUs at cost and reuse old data center hardware to get lower prices than anyone else.
If you're not cheaper than buying a PC or console you can't win. No one wants to pay more for the privilege of input lag and compressed video, or getting in trouble with their ISP if they have a strict data cap.
I interned for Sun and then worked as an MTS in Sun Labs for a couple of years. I miss Sun; I think they were very much an engineer's company that was spoiled by two things: big success in the early workstation market, and the dumb luck of the dot com boom. Sun hardware was solid (even though they fell behind the curve because of mismanagement of a couple of CPU lines), and its kernel (Solaris) was one of the well-engineered kernels ever. While any business makes some bad business decisions from time to time, one thing that was fatal was a crippling enterprise focus that failed to understand the huge growth opportunity that OSS and Linux represented. It was growth in a direction they not only didn't understand, but refused to understand, study, or adapt to.
Sun's heyday was in the boom. The fish were jumping in the boat. So naturally they were building bigger and bigger boats.
There was always the one-off ideas that might have gone here or there, but that core server cow just seemed like an endless source of cash. Thus they neglected the workstation market and ironically, the market for anything bigger than one single server rack. They didn't understand horizontal scaling, and the rise of cheap-but-replaceable consumer hardware like how Google did things was alien to them. They poo-poo'ed Linux, they killed and then unkilled Solaris x86, and a number of other things.
I do miss Sun though. As far as engineering goes, they were a very serious company full of serious engineers. Basically the polar opposite of 10X tech bros and startup culture.
Oof, the killing and subsequent unkilling of Solaris x86 in 2002 brings back very bad memories -- Sun management at its worst. It also highlighted the relative power of Sun's engineering in that everyone in Solaris knew it was the wrong decision, and we more or less disobeyed orders: during that period (January 2002 to August 2002, when it was reversed), we didn't change our treatment of x86. (And in particular, breaking x86 was grounds for a putback to be backed out.)
When Solaris x86 was unkilled (and then became increasingly important as x86 eclipsed SPARC), there was damage done that I don't think we ever fully repaired.
Agreed. When I was in the labs (2007 - 2010), my workstation was an AMD with Solaris on it, with a modern window manager and all, with IntelliJ and a great development environment. I almost didn't know it was Linux. But by then the ship had long sailed.
I worked at sun (sunsoft) right out of school near the peak. It was great. I was very excited to have all of the sources for sunos easily available to read.
Later, in grad school I went to work at a startup… google. For me it recaptured everything I liked about Sun. And had the same CEO.
What of Jini, JavaSpaces / Linda, JXTA, "grid computing"?
Were they too early? Dismissed as (Bill Joy's) hobby projects?
At the time, I was very enthusiastic. Especiall grid computing. So much so that when cloud computing arrived, I couldn't recognize the sea change. Square peg, round hole.
We even POC'd some Jini support. Demo'd for hardware manufacturers, customers, our dealer channel. Customers loved the idea.
But like UPnP, Jini failed to get traction.
As for JXTA (peer-to-peer), although I didn't gave any skin in that gane, I really expected it to vecome the norm. eg My brother (for his ISP) POC'd video delivery in anticipation. But that got mooted pretty quick.
Arguably, AWS Lambda (et al) was is "dumb" grid (run anywhere in asandbox) and the OpenClaw agentic (madness) is the "evil" incarnation. (I'm aware of efforts like Emerald AI (et al) to make a "smart" grid.)
RE: JXTA, right around the turn of the century, it felt like there was an opportunity for a globe-spanning peer-to-peer application layer, based on content-addressable storage.
DHTs—Chord paper was 2001—started popping up. The big software vendors looked at the architectural (if not legal) success of Napster & the other P2P networks and were invested in finding legitimate applications. Open standards were seeing real adoption left and right.
But it didn’t happen. Maybe simultaneously too late in the Internet’s evolution and too early.
Too late because the big kids were involved. Especially Microsoft, who would never allow any standard they couldn’t EEE to emerge. Too early because the players like Google who later could muscle through core infrastructure standards weren’t there yet.
And now it’s likely too late, with mobile embedding a client-server model with the weight of 10B devices.
reply