482794793792894

As I understand it, English is your mother tongue. If so, that's probably why you don't have this issue.

For me, French is my mother tongue and I live in France. So, there's lots of things that I'd want to research that are specific to France (laws, culture, geography etc.) and then obviously, if you speak French fluidly, you get much more precise and detailed information for these in French texts.

If you're lucky, the English text is just a bad translation, but more often than not, the English text assumes that you must be some guy from a foreign country that really doesn't care about specifics and instead just wants an overview.

On the other hand, if I need to look up technical information or most international science, then English is the lingua franca, what gives you the best results in most cases.

In some cases, I'll even try both languages, just to make sure I'm not missing any useful information or to gauge which language gives better results (for example when a globally usable technology happens to be exceptionally popular in France).

While that would also be a somewhat useful measure in this context, there's very little correlation between the size of the codebase and the size of the binary.

Programming languages and styles can vary in verbosity a lot. For example, if UEFI is written in some form of assembler code, then you quickly get a lot of lines of code while the binary doesn't grow particularly. On the other hand, high-level programming languages like Java, or even moreso functional and logic programming languages like Haskell and Prolog respectively, can generate huge binaries out of even just a few lines of code.

Filtering RSS depends on your RSS client.

On the desktop, QuiteRSS [1] is really good at it.

On Android, SpaRSS [2] isn't entirely terrible at it, though there might be better ones out there (I've essentially only looked on F-Droid).

[1] http://quiterss.org/

[2] https://github.com/Etuldan/spaRSS/blob/HEAD/README.md

This is a notion that sounds great at first, but it's entirely shallow.

- There are tons of information pieces that functionally need to be private, for example passwords, and tons of information pieces that better just should be kept private for your own benefit, like medical records.

- You're not helping us customers. If every company knows everything about us, then every company can exploit our mental vulnerabilities to get us to buy more things we don't need.

- Privacy is a basic human need. Lack of privacy can lead to severe mental issues, as illustrated by Panopticons.

Well, you can just as well be best friends, even if you're wanting to mold each other. Both parties just have to be open-minded about it.

You might even see it as positive to be challenged in your ways, as it helps you to move yourself forward. For example, if you're a couch potato, you might actively look for a sporty partner in hope of being motivated to do sports.

Alright, but it really doesn't seem to me like fixing this issue for you would require breaking the search for bilingual people. There's gotta be so many better ways to resolve that.

Yeah, it definitely feels like Google has gotten into this phase of a monopoly where you just stop trying. It was specifically Google that used to have all kinds of advanced user thingamabobs, now they actively make it harder on advanced users.

The problem with X11 is that it's everything-and-the-kitchen-sink. You can't solve that by making another everything-and-the-kitchen-sink. You need to cut down in some places and modularize the other things.

One perfectly legitimate way of doing that is to do one of those things and ask others to do the other things. Development would not go faster, if they put those other aspects at the end of their To-Do List as well.

Last weekend, my dad needed new printer cartridges and so we went sifting through the internet for different offerings. By chance, we got onto a page on the manufacturer's website, which had images of all their cartridge packs. Among those, we also found an XL version of what we initially thought to buy.

So, there we were, needing exactly this feature. If I didn't know that it's impossible for them to have developed this in such a short time, I'd be a little freaked.

Thankfully, though, TinEye served the exact same purpose...

That's not the point they're making. What they mean is that if they consider side projects as potential criteria for being hired or not, they'll lose the fun in those side projects.

Because they'll then try to make every part of the code perfect and with complete documentation for everything, probably spending more time trying to present it rather than working on it.

> Instead of seeing a dollar amount associated with their purchase, app developers show the purchase amount as coins. This could take the sting out of spending cash, Amazon has believed.

I'm fully aware that Amazon is not the first company to be doing this, but does this not break contract law? They're actively trying to trick people into spending more cash for a product than they rationally would.

Like, where's the line between this and just offering people a joint before they sign your contract, so that they feel easier about spending money?

> Note that there is no picker for <input type=time>. We decided not to support it since we think it’s easier and faster to enter a time using the keyboard than selecting it from a picker.

I've thought this so many times, even on my phone where typing is less accessible, I still prefer it over those analogue clock face inputs.

With such a clock input, I'll often hit the wrong time, either an hour/minute too late/early, due to my apparently fat fingers, or 12 hours wrong, because I live in a 24-hour-format region where normally on an analogue clock you read things in 12-hour-format and so my brain thinks "8 pm" and enters "8" when it should have chosen "20". That doesn't happen with typing, because digital clocks almost always display 24-hour-format.

And even worse, in an attempt to speed things up, someone came up with the ingenious idea of directly advancing from hour input to minute input as soon as some input has been made. So, my first few wrong inputs then mean that I have to find the way to get back to the hour selection multiple times.

Nah, it's been on Mozilla's To-Do list for years already, just realistically not ever really a priority.

And I'm also pretty sure they've already been actively working on the implementation prior to talks with those companies. I think, I remember reading about first design steps at the start of the year already.

Well, Firefox is not Chrome. Firefox usually supports things more completely than Chrome, partially because that's just what they do, they safeguard webstandards, so delivering a standards-compliant browser is a main-goal, but in large parts also because the community will make Mozilla go the extra mile with code contributions, if they don't do it themselves.

And a Mozilla dev, Manishearth, has commented above that he is in fact currently looking into making it configurable.

The reasoning is that this is a brand-new feature that just landed in the Alpha release of the browser and they're just not done yet with every secondary implementation aspect.

Manishearth, who's a Mozilla dev, commented in another thread that he's currently looking into making it configurable.

I also find that my brain wrongly pattern-matches words that form a different word when reading the letters in reverse.

So, I for example often misread "was" as "saw" or "on" as "no".

In our system, it becomes challenging to find the start of the next line when reading long lines of text. This is pretty much the main reason why sheets of paper or modern webpages are only as wide as they are.

I don't think this sort of bottom-up approach will make you happy, though. You never know what kind of technology you need tomorrow and whether your Chromebook allows you then to handle that. And fixing that then is not possible, not with a bit of sysadmin work.

Uploading files would become a chore, as you'd always have to copy them over from your actual Home-directory to that Firefox-user's, but yeah, it would add another thick layer that attackers would have to get through.

Mind that Firefox is also getting sandboxed tabs as we speak, so yet another layer that attackers would have to get through, which wasn't in place at the time of this attack.

You're describing a sandbox. You run the security-vulnerable routine inside a separate process and give this process the most minimal read/write-permissions that the routine can still work with.

Flash itself has been sandboxed inside Firefox's Plugin Container since forever and Firefox is getting a sandbox around tabs as we speak.

But you can break out of sandboxes. By either exploiting a bug in the OS that bypasses process permissions or by finding a hole in the sandbox that allows you to do things.

I imagine, for example, if you want to upload a file, then the tab-process has to talk to the less restricted main-Firefox-process, which has to then open up a file-chooser dialog and give control to the user.

But it could for example be possible to somehow malform this request to the main-Firefox-process, so that the file-chooser crashes and just hands over a random file, before the user has even seen the dialog. (Obviously, I'm not going to come up with an actual security vulnerability on the spot here.)

This kind of vulnerability can't be fixed with a sandbox. You need some way to upload files, for which you'll need filesystem access in some way and to pretty much the entire Home-directory.

Theoretically, you could require the user to copy the file into a separate "Upload"-directory and then only have read-permissions to that directory, but that's hardly user-friendly and would probably end up with some users keeping their entire Home-directory underneath that Upload-directory.

This isn't exactly a bugfix. It was a feature request and one that conflicted with another feature (Shift+Mousewheel to go back and forth in browsing history; has now been moved to Alt+Mousewheel).

There's some progress happening for this in AnySoftKeyboard: https://github.com/AnySoftKeyboard/AnySoftKeyboard/issues/26...

Open-source projects tend to stay below 1.0 much longer than commercial projects, because there's no rush to release a "1.0".

If your software works well enough, people will be using it, no matter what the version number is. You can't stop them from doing that and you really don't want to stop them from doing that either. You'll never get outside contributions, if no one uses your project.

And if it doesn't work well enough, well, it's not like you're selling it for money. You're never going to give a guarantee for it working, whether it's past the 1.0 or not.

Of course, you're going to try to not needlessly break it, if there's people using it, but again, you'll have people using it long before the 1.0. Most likely you're going to be using it yourself, as soon as it's somewhat usable.

Probably a case of having engulfed the industry so much that just throwing money into the industry will actually pay out for them in the long run.

And it's probably also just nice to be able to bite Google and Microsoft in the butt here. Those do benefit from a healthy web and both very much need the PR of supporting webstandards, but they could also both benefit a lot more from controlling a platform like MDN and then sneaking in pseudo standards here and there. So, Samsung helping out with MDN makes it even harder for one of those to build up their own version.

Lastly, Samsung does ship their Samsung Internet Browser on all of their Galaxy devices, which has got to be a somewhat significant share of daily internet users. Currently, that's Chromium-based, but they could be looking to eventually follow Google and Microsoft in making up webstandards.

They've also already invested into Mozilla's Servo, so maybe they're also just trying to build up a partnership with Mozilla to help to take on those giants.

As far as I understand it, you need tight coupling between the browser and the OS to implement the sort of deep-reaching DRM that Netflix/Hollywood wants for 1080p. That would explain why Edge on Windows and Chrome on ChromeOS can do it.

Personally, I see it as a plus that my browser/OS combo does not support this. There have to be horrid security implications that just wait to be unturned.

If I have to use Windows, I can't do it either. But give me virtual desktops, a tiling window manager and (sensibly laid out) keyboard shortcuts for everything, then I'll often even forget to use my second monitor.

Ad-blocker for Android: https://f-droid.org/app/org.jak_linux.dns66

Mozilla Blog post: https://blog.mozilla.org/blog/2017/10/18/mozilla-brings-micr...

Pro gamers in highly competitive, reaction-based games (such as most first-person shooters) usually disable it, yeah.

And I'm not an expert in this either, but I'm pretty sure double buffering is the norm, whether you use V-Sync or not.

One buffer in which your graphics card works on frames (I'll call this "graphics card buffer") and then a buffer into which finished frames are moved, so that your screen can read them out in peace (I'll call this "pre-screen buffer").

There's also "triple buffering", which introduces another one of those graphics card buffers, so that when a finished frame is being transferred from that first graphics card buffer to the pre-screen buffer, then your graphics card doesn't have to wait for that transfer to finish and can instead start working in the second graphics card buffer right away. (And then it transfers frames from those graphics card buffers in alternating fashion.)

So, the delay that V-Sync introduces is not that. What V-Sync does, is that instead of transferring finished frames from the graphics card buffer(s) into the pre-screen buffer as soon as the frame is finished, it waits with the transfer until your screen has finished with reading out the previous frame.

If you don't wait (have V-Sync disabled), your screen will read out some part of the previous frame and then read out the rest from the new frame. On the screen, you'll see this break between previous and new frame as screen tearing.

So, assuming your screen can display 120 frames per second and your graphics card happens to finish 120 frames in a second, then V-Sync will not introduce a delay. It'll wait once with transferring the first frame, but then they'll be in sync and no further delay should occur.

However, if your graphics card is able to calculate 240 frames per second (and your screen still does 120 frames per second), then with V-Sync, the graphics card buffer will be transferred into the pre-screen buffer only 120 times per second, making the graphics card slow down to 120 frames per second as well.

Without V-Sync, the graphics card buffer will be transferred 240 times per second, regardless of how often your screen can read it out from the pre-screen buffer. This means a frame will get loaded into the pre-screen buffer as your screen is reading it out. As a result, you'll get screen tearing and one half of your screen will be from the new frame, with a 1/240 s = 4.167 ms delay, the other half is still from the previous frame with a 2/240 s = 1/120 s = 8.33 ms delay.

So, a few numbers:

120 FPS with 120 Hz screen = 8.33 ms delay.

240 FPS with 240 Hz screen = 4.167 ms delay.

240 FPS with 120 Hz screen = ½8.33 ms + ½4.167 ms = 6.25 ms delay on average.

480 FPS with 120 Hz screen = ¼(1/480) + ¼(1/360) + ¼(1/240) + ¼(1/120) = 4.34 ms delay on average.

960 FPS with 120 Hz screen = 2.83 ms delay on average.

960 FPS with 240 Hz screen = 2.17 ms delay on average.

Microsoft is a for-profit company. They build up reputation to use it. They have no reason to just amass it.

When they open-source software that is specifically to try to get the dev/tech community somewhat back onto their side. Which is the customer group that complains the loudest about their data collection and which has the only real chance of wandering off to the competition.