spronkey

Such a ridiculous stance for Apple. I am 100% convinced that the xMac would double their desktop computer market share.

And replace them yourself without catching on fire, or whatever "safety" issue they keep blabbering on about...

Ho-lee sheee-yt

The screen bezel was symmetrical enough to keep my OCD in check.

Ignorant comment. Very easy to design a) a dual power circuit and b) charging hysteresis to not mame the battery.

There simply is no good reason for the port placement.

2-3 years later when your proprietary LiPo dies, you'll pat your younger self on the back for choosing a standardised battery. You will repeat this over and over again for every time you choose a standardised power source over a proprietary one.

Remember that the thermal efficiency of an ICE is far lower than that of an electric motor, plus electric cars can use kinetic energy recovery so get even higher efficiencies.

> This is only really the case where the prototype was fundamentally solving the right problem in the right way to begin with and the subsequent changes are incremental in nature. If the design of, say, a microcomponent is flawed from the outset or it did the wrong thing and you have to re-do it, those "stiff" tools slow you down.

This. So, so, so, so much this.

I absolutely agree that getting the contours of the tool right (nice analogy there) is (one of) the hardest parts. The main issue I find when using strict, type-driven FP langs for "first draft" style implementations is that I waste time with the unavoidable ceremony that most of these languages require, when what I really want to be doing is probing around to discover the rough edges. The "my last name is Curry" style of FP almost requires you to declare these edges up front as you code.

I actually find that TDD is even more useful in FP contexts than in procedural - mainly because a) it's a good way to help think about the shape of the tool before building it, and b) the FP implementations are often more mentally complex with recursion, pattern matching, and other such things that (IMO) require more brainpower to grok than simple procedures, and to be honest I just find myself needing the tests so I don't go mad trying to be a human compiler. I think even the most staunch TDD fanatics wouldn't try to argue that it's a fast way to prototype.

These days I find myself reaching for dynamic languages with gradual typing for prototypes that might hit production (JS+TS, Python, even PHP). When I'm satisfied with the general shape, I'll add a few type hints here and there to make my IDE friendlier. After a while, usually at the point where there are large additions to requirements, I'll find myself rewriting at least a chunk of the original in a completely different manner, usually in a more type-driven manner, usually with a more FP slant, and often in a different language with more strictness.

I would like to see more mainstream languages support both type-driven FP and simple procedural code without using Haskell-inspired syntaxes or turning into the incomprehensible mess that is Scala. Java is slowly morphing that way, but it still lacks some of the FP fundamentals for when you do want to go full-zealot.

Both Dell and Lenovo are getting worse when it comes to easy repair though. Newer Thinkpads have been nightmareish for keyboard replacements.

Time machine is glacially slow, and it is finicky to use with network storage, and doesn't play nice with non-macs. Newer portable Macs had been annoying to use with most existing external storage until rather recently because of Type C.

The contrast effect at play. Make the stand $999 to make $200 seem like a reasonable price for the VESA adaptor, when in fact it should be built in to the display like it is on basically ever other pro-level display.

They can justify the performance to a point. If it costs twice as much as a competing system offering similar performance, reliability, and service, it becomes much more difficult to justify.

I think you're onto something, but I don't think it's as simple as just having a "light theme" and a "dark theme".

I think that if we're going to have toolkits that support custom, nested widgets, those widgets need to be designed to support the context they are in. There will always arise situations where normally-light widgets need to appear on a dark background, or vice versa. The nested path bar example is exactly this - it's a widget that supports a single context (light background), but is having two contexts forced on it by leaky style cascades (light text, but also light background).

How about we bake the concept of "light" and "dark" into the widgets themselves and take advantage of the cascading nature to switch the theme of a widget depending on the context it is in.

Realistically though, GNOME 3 was rather short-sighted when it came to themes. Windows 95 showed us the way 24 years ago: you can change the colours of anything you want. You can tweak the size of most things. You can change the fonts. You can change the icons. Simple API that gets applied on top of an existing theme. Expand this for 2019 with dark and light variants for each theme, and I bet we'd satisfy almost all users.

Well said.

The Firefox/Thunderbird example is absolutely ridiculous - it's not up to these application developers to decide what icon or colour the user sees. It's up to them to provide defaults. As you say, it's clearly still Firefox - but even if it weren't, there are several good reasons I can think of that a distribution might want to change it.

What bugs me is the attitude that the solution is to reduce the usage of themes, as opposed to improve the theme engines and app dev toolkits. Why shouldn't the OS be able to impose a global stylesheet for colours, images used for semantic icons, sizes of common elements? If I, as a user, want to starting fiddling with my system theme, is it not likely that I might want all the apps on the system to play ball? Sounds pretty jarring to me to have one or two apps with their stubborn hardcoded "branding". (Oh wait, that's what we already have with Electron apps that don't respect the OS theme or conventions, and they suck!).

Oh, apps can't be restyled without manual work they say. "Until this perception changes..." they say. NO!

In an ideal world, applications could be built easily in such a way that allowed them to be themed without causing major UI bugs. The fact that this is such a large issue with GTK apps is surely further evidence that GTK has a bit of a problem - especially considering that other UI platforms are able to do a better job.

Perhaps - and I'm really pushing it here (/s) - solving the root causes of issues arising from custom themes relating to sizing and spacing might actually have other benefits as well. Like better support for UI scaling. Maybe the scope of themes needs to be reduced a little so it's easier for application developers to support?

Web Fonts are a bit different - it's still semantically just text, and you have the option to override with a user stylesheet.

For many websites, web fonts have been an improvement, especially considering the sorry state of "web-safe" fonts back in the day.

I respectfully disagree for the large part. My own brain seems to have no issue coupling functionality to visual design. Yes it's probably less optimal for novice-to-expert transition than having colour variants, but conversely it also gives stronger immediate affordance as to what subreddit you're using..

As strange as it may seem, blind people can be quite good at resizing images.

Plenty of good reasons - sometimes people like to shift common controls to be more familiar with their habits. Sometimes it's handy to shrink things like title bars. Sometimes the awful text rendering on Linux systems needs a bit of tweaking not to drive you mad...

I hear many people continuing to say that Intel are "cutting security corners".

Are they really? I don't have an extremely deep understanding of Intel's implementation of x86 ISA, but I do know enough to say that so far we've been able to effectively mitigate almost all of these attacks with existing instructions available on the Intel CPUs. That doesn't mean that they are still not open to other variants of these attacks - but at some point you have to assume diminishing returns. Spectre is still very difficult to exploit, for example.

Perhaps this has little to do with Intel and more to do with software authors cutting corners? LFENCE and SFENCE are reasonably well documented, after all...

We're not really sure yet whether TSMC have leapfrogged Intel in the longer term though. Intel's 10nm issues seem to have delayed their smaller process nodes in the medium term, but by how much is yet to be seen. It seems, for example, that Intel 7nm isn't in quite as much trouble as one might expect.

It's also naive to dismiss the possibility for Intel to have learnt a lot from some of the failures in 10nm that will prove useful in accelerating node development in the future.

They can compete in certain workloads. As a computational tool however, desktop Intel CPUs can be optimized far, far beyond the capabilities of any A-series CPU.

Don't forget that Intel CPUs have things that A CPUs are missing like QuickSync, AVX2, massive PCIe interconnectivity.

Whether the A-series CPU could be modified into something competitive on that front is yet to be seen. Whether this actually matters considering the state of our compilers and software development is yet another question.

It's certainly better at multithreaded workloads than single threaded. But performance per watt is nowhere near Intel or Ryzen parts.

Anandtech went downhill when they lost Anand. Not sure what the hell he could possibly be doing do that's useful to Apple, but the conspiracy theorist in me wants to think it was Apple getting him out of the media.

Personally I believe this is one of the major gaps in Scrum, and there is no prescripted way to solve this problem. XP's focus on technical aspects is much better in this regard, but the possibility of runaway technical debt still exists.

There are so many places where this can sneak in and become an issue, too:

- The development team can groupthink, underestimate and/or fail to account for technical debt payback in planning poker. They may estimate the cost for the new feature, but not include any time for refactoring to keep the codebase healthy

- The Scrum Master may not shield the development team from pressure to deliver coming from the product owner, which may cause the team to cut the above corners

- Codebase health may be split out from vertical stories into its own tasks that get deprioritised by the product owner

- Even if the development team identifies the need for codebase health, this may not be communicated back to the product owner in a way that makes business sense ("but we can still get this feature out the door quickly and fix the mess later, right?" - yes, once or twice, but the downside is a slowing of velocity)

- Even if the team started well with ground rules the Scrum Master is supposed to enforce surrounding technical quality, the Scrum Master may not be effective in enforcing the process - either because they lack authority or because they lack the ability or knowledge to do so

Among several others.

In your situation, the big red flag is that the team predicted the issue many months prior. The process has failed to extract that information from the team members and deliver a consensus between them and the product owner.

Though ultimately, as with any project, if the product owner has more organisational authority than the development team and chooses to exert this authority, no process will be able to save you.

AFAIC, the only thing that works with a fixed deadline is a variable scope. Which is basically a tenet of Agile.

The alternative is some sort of sub-iteration hybrid where you attempt to fix deadlines for much smaller units of work and constantly revise.

This is OK for some industries. But 2/3rds of a car doesn't quite sell...

Hmm, it's possibly more the font, your system's font rendering, and/or your display than the colour.

It's an easy pass for WCAG AA with 5:1 contrast ratio, but I think it's marginal for WCAG AAA as it's about 20px in size, but not bold.

If you're finding that hard on the eyes it might pay to check your display's brightness with a colorimeter. Most displays are far too bright out of the box.

I don't get it - what's wrong with the colour pairing?

If you think about it, the emissions already occur when trucks drive goods to the shops, then people drive to the shop then drive home.

SSAI - you write your own player and do it that way?

Even better, haha! Seriously impressive work though - one of these projects that show just how absurdly bloated and slow mainstream OS development has become.

Also for reference for those unfamiliar with the difference in greys: http://actsofvolition.com/images/screenshots/Display-95-thro...

May I suggest using the Windows 2000 warm grey instead of the Windows 95 grey?

It does a lot to make the UI feel less dark