Re: Making me feel old
This kind of thing is still cropping up in image files…
12110 publicly visible posts • joined 16 Apr 2007
That's just the inventory system's way of saying mañana – not now. The supply chain is still broken but it's now more a question hiccups as opposed to out and out failures, for which the just-in-time mentality of the car industry is mainly to blame.
The bigger problem is that the car industry now wants more, more powerful silicon at the same time as world and his dog does, but new capacity is coming on line and older fabs will be retooled.
I'd also be surpised if the directive stipulated CE only, or even if the crown wasn't allowed as an equivalent, just means that the glasses couldn't be sold elsewhere in the EU. Lots of products have CE + loads of other symbols. Still, pointless trying to discuss this with the red top crowd. Please ignore me, while I mumble into my pint glass.
There's no need for the messages to land in the cloud in the first place, but if they do, it's better to encrypt them beforehand on the phone, as Signal does. https://support.signal.org/hc/en-us/articles/360007059752-Backup-and-Restore-Messages
Also worth enabling a timeout for messages: let's face it, in general, most messages are have a half-life of about a week.
I can't agree with your assertion that people know that they're interrupting or that others are too timid or polite to interrupt. Personally, I've no problem with making myself heard but it's well-known that this does not apply to everyone, and this is a major problem with meetings in general, which tend to favour extroverts and sociopaths.
Whether an AI watching people's faces is the correct solution, I'm not so sure. Training people to be more assertive and conveners on reining us loudmouths is probably just as important, but I can see advantages, especially for conveners, in a system that might pick up on some visual clues
It seemed to me as hard as it was for x86 to scale down in power(for mobile) it was as hard for ARM to scale up in performance/scale(for servers),
Once the legacy x86 code is gone the difference is indeed small, though ARM now has more experience in asymmetric designs with big.Little now standard. But what ARM really does offer in addition is the ability for custom hardware: hardwiring certain encryption or codecs can make a huge difference overall.
Some edge servers serve as proxies for the x86_64 servers so need to be able handle the relevant code well. But the article also points out that they are also actively evaluating ARM chips. They may have simple decided that chips which provide the best current performance / power tradeoff are the Epycs and they are currently not at the scale large enough to warrant their own designs.
Why bother when they control the whole OS? If they want to, they can add a TPM unit to stop of OSes being installed but "baking in" telemetry would be an invitation to class action lawsuits.
But seeing as most people are already more than happy to give them the data, why make additional work for themselves?
The main reason for wanting to control design is time to market, with things like AI but also custom encryption or other acceleration such as codecs being key differentiators.
Exchange is rapidly becoming the next Flash due to the monoculture. The arms race is hotting up and Microsoft has thus far not demonstrated that it can keep ahead of the hackes and, once Exchange is hacked, the hackers usually have the keys to the kingdom.
It may be interesting to see how liability due to software flaws changes in the move to SaaS (Microsoft is pushing this because of lock-in, CIOs because of costs). Thus far software companies have been largely exempt of liability as long as they can provide an update for customers. It will be interesting to see the jurisprudence in an SaaS world.
LEO constellations are a disaster waiting to happen but they are also a good example of how much Silicon Valley loves to move into unregulated markets and then bully regulators into silence. Unregulated markets almost guarantee network effects for first movers. One of the reasons for this is that unregulated markets often rely on unpriced or underpriced common resources in what is known as the tragedy of the commons: fisheries are a good example. Providing voice and data services via LEO is a bet that the costs of simply maintaining the satellite infrastructure will always be cheaper than the combined infrastructure and licence costs of ground-based solutions. In addition, and this is where the comparison with fisheries comes in, no one knows much about the long term consequences of LEO. Even though the orbits decay naturally, without regulation it's easier to imagine the most useful orbits filling up quickly on a first come, first served basis. And, even if the orbital decay means that there should be less junk in space, we still don't know anything about the potential consequences of lots of satellites terminating in the upper atmosphere, though the extensive use of aluminium should give cause for concern. In the absence of regulation, all profits will be privatised and all damages will be socialised.
The more typecasting you can do as part of ETL the better: pgloader is a good example for this. But as soon as you want to start indexing for queries you're going to want to make tradeoffs.
This approach sounds very much like being able to run prepared queries, at will and via batches (renamed as "rollups" by those clever chaps in the marketing department), in near real time. This will certainly drive up the RAM / server requirements.
The number of syntax changes were limited and most of them could be handled reasonably gracefully. It was also fairly painless to forward-proof Python 2.6 and 2.7 code for then eventual transition to Python 3 only. Still, it was only when explicit support for u"" strings we reintroduced that the real gotchas went away
The arcane syntax, including backticks, was removed before all this. But I still find myself wishing for the return of the print statement.
Developers still struggle with some of the internals, especially for C extensions, which may require extensive refactoring for no perceptible improvement.
But worst would be the tendency to add fashionable stuff that really only covers edge cases: type hinting and the awful "walrus" operator are my own pet hates.
Rinse and repeat the Django example with almost any largish web framework in any language. Tramlines was written years ago for Zope to allow for better handling of file IO, and Pyramid more or less mandates this.
This isn't related to the language but to the tendencies of developers to try and do whatever they need to do with the tool they know best.
Having spoken to a couple of brewers about it I think there are two main reasons for the popularity: the strong hops were the biggest break from that bland MAB (middle American beer), that was often the only thing available. And, it's difficult to go wrong because no one will know if it's over- or underhopped. This is one of the reasons behind it in the first place: the hops masked the cheap beer and long and unsuitable travelling conditions.
Personally, I prefer gentler bitters where the balance of malts and hops is more difficult to fudge. But variety is the spice of life!
I'm fairly familiar with the specification and, while the descriptions are indeed at times unclear, you can still work directly with the schema. I've worked with far worse; even the post 2006 extensions are documented and the schemas provided.
Internally, I suspect that some of the inconsistencies cause nearly as many problems for Microsoft as for anyone else.
Real barriers to entry are things like taking XLSM off the table, but more worryingly, the move towards "collaborative" work via that cancer that is Sharepoint. OOXML itself relies on the zip format, which doesn't lend itself to changes. It took them a while but Microsoft did realise what a wonderful lock-in the cloud is and has since had CFOs hammering at its doors chanting TCO, TCO, TCO…
While there may have been some obfuscation, I think the real problems with understanding the spec are rooted in essentially transliterating the existing, and undocumented BIFF specification.
Microsoft was definitely guilty of foot-dragging and also most certainly abused the standards process by bribing fast track approval. But, at the end of the day, the transitional specification is good enough for most interoperability. And, having worked with the ISO working group for the last 5 or 6 years, I can confirm that they are still engaged with the process to improve the documentation, which has significantly helped my own OOXML library. During this period, however, there has been no interaction with either The Document Foundation or the OpenOffice team.
And, FWIW, the feedback from ISO is that ODF, while probably the better format, has largely been left to languish.
There is a good financial and standards-based rationale for making that single suite LibreOffice
Possibly, but stability and UX are also a problem. For CFOs the licence costs are less of a problem than potential retraining costs. And LibreOffice's UI has been the victim of some very poor decisions. The ribbon in MS Office is a real nightmare but much of the reworked UI was well done. At least on my Mac, LibreOffice is not particularly stable. And there, for Excel at least, there is the add-in ecosystem in which some companies have invested heavily. All this makes switching more difficult
When it comes to the differences betweem transitional and strict versions of the OOXML specification, these are generally minimal. A bigger problem is that they use completely separate namespaces making handling qualified element names a royal PITA. And the undocumented requirements for MS Office. These are, fortunately, generally documented in the implementers notes but it's not possible to automate their enforcement.
But it's good to see the LibreOffice team engaging more meaningfully with the specification. Many long-standing compability bugs seem to derive from simply not reading the OOXML specification. Again, when trying to persuade companies to migrate, having poor compatibility makes you, and not Microsoft, look bad.
SQL does it all the time: True, False or NULL and indeed the resulting 3-valued logic is the source of innumerable problems. But at least that's going to be consistently shit across runtimes.
Behaviour that changes like this across runtimes is a material defect and a class action would be reasonable.
Samsung has already been found out for excessive tracking from their TVs.
On their phones they make extensive use of third parties, including Microsoft, and just gets users to agree to whichever EULA is required.
This doesn't make them any better or worse than Apple. But, at least, so far they haven't announced that they're saving the world from child pornography.
The military was indeed very impressed by early models but the energy problems: batteries don't last long, petrol engines have their own problems quickly put paid to them as soldiers. But for reconnaissance or camp work it's possibly a different story.
For us it's natural but being able to use two legs and stay balanced while moving and using force is incredibly difficult. At the same time, it is an extremely practical ability when working outside factories and office space. Imagine how useful this ability would be, for example, for exploring foreign planets, though no doubt the military will have first pick.
And the research project and presumably the relevant patents will be around the necessary components and AI models that are required for this.