Genuinely curious, only serious answers, please: can someone living in Turkey explain how the government can justify ordering a ban while publicly using Twitter themselves? What am I missing?
To add to the other answer you received, Turkey was in the habit of blocking social media after things like bombings well before the state of emergency was announced.
The official power comes from a statue which allows restricting communication when "made necessary for national security purposes or a situation arises which might seriously impact social order", this was the justification for blocking after the bombing at Ataturk airport. People sharing videos and images of attacks is not good for the public morale, and that's ostensibly such an important concern that it merits blocking social media.
This current round of blocks has suspicious timing and extent but as my sibling points out, it's a state of emergency, they don't need justification.
They are not "banning" in the sense of disallowing or prohibiting. They just slow it down to the point where it is no more usable. Media is only as good as they serve to the needs of the government.
As for the justification, nowadays they don't really justify anything, they just do, and it doesn't matter if it is unlawful or not. Especially after the coup attempt, there's this state of emergency situation which allows the government to bypass the parliament which pretty much translates to no justification for anything, capability is enough and it is not difficult to find stuff to use as pretext. Many of the government's recent actions are gross violations of constitution and several other laws, all possible due to the emergency status.
uMatrix offers a feature to randomly pick a UA every 5 (configurable) minutes from a set of configurable UAs. This works, although GMail might complain about the UA being too old. Reloading GMail resolves it.
uMatrix offers a feature to randomly pick a UA every 5 minutes from a set of known UAs. This works, although GMail might complain about the UA being too old. Reloading GMail resolves that.
EDIT: Replied to the wrong parent, please ignore in this context.
My primary reason is that I don't view a page on the same display and machine as the author, so more often than not the presentation is sub-optimal or entirely unreadable locally. Custom fonts are similarly abused like low-contrast text (grey on white).
Also loading via JavaScript and changing the fonts of an already rendered page disrupts my reading. If you want remote fonts, load them from the beginning, or if this isn't possible, just don't, please.
Another justification for disabling remote fonts is that it's one security critical interpreter of complex data which, when disabled, doesn't adversely affect the presentation, whereas on most pages disabling images does and cannot reasonably be disabled. The latter justification may go away with Mozilla's Oxidation efforts with time, leaving just loading time and readability as arguments.
Yes, this appears to be correct - the Firefox API supports filtering out of the box. If you check the readme on the WebSocket companion, it specifically mentions Chromium based browsers, assumedly indicating it's intended for them.
There is also a note on the normal uBlock repo that says that Firefox has an extra feature with a link to inline script tag filtering, which says it does not work on Chromium based brownsers: https://github.com/gorhill/uBlock/wiki/Inline-script-tag-fil...
To be sure there is no confusion, it's possible to block inline scripts with Chromium, but not on a per-inline script tag basis.
Per-inline script tag filtering is possible for Firefox, but the feature relies on "beforescriptexecute", which is planned to be deprecated in Firefox as well[1]. As a result I have ceased to create "script:contains" filters and favor filter solutions which work on all browsers.
Thanks for the confirmation. I expect new engines like Servo to support content and request filtering at a lower layer for efficiency reasons, while of course still exposing it to JavaScript as needed. Opera already does this out of the box, though I don't know the internals and it's not as full featured as uBlock Origin. Without uBlock Origin and uMatrix, the web would be unusable from a UX perspective. thanks gorhill and friends!
Not trying to downplay issues or shame another system, but if you compare Linux's HiDPI support to Windows, it doesn't look so bad anymore. For one, it's more likely to find apps that scale on Xorg/Wayland than on Windows, most Microsoft Windows official system apps included. Simple things like apps with list controls that have a huge number of entries where you're not able to resize the window while other more prominent MS apps waste white space like macOS and GNOME is an interesting phenomenon to observe.
> In order to continue the development in a reasonable speed, we stop conforming to the specification of ZFS. As such, we can no longer call it a ZFS implementation.
They have their valid reasons, but it's a shame, because an implementation of the very complex ZFS filesystem in Rust would have been a great thing to have. Not to mention the ability to mount redox zfs images with illumos or FreeBSD or ZOL.
I'm also disheartened by the description of TFS's layering. It seems like they go with block level encryption instead of something with authentication.
Yeah, I wish they had teamed up with Robigalia in order to build on seL4 or at least translated that 1:1 to Rust, foregoing the verified nature of seL4.
What we always see on programming languages is that when shortcuts for arriving faster at our goals are taken, usually they give ammunition to remarks of the sort "language X cannot do Y".
Apparently most lack vision and need to be proven wrong.
So I hope they manage to just use Rust and Assembly.
Because Redox's aim is to be as little non-Rust as possible. I agree it'd be ill-advised to rewrite seL4 rather than use it, even though it's been a while since a revision was verified, because it's been battle tested, is continually improved and small enough to trust.
We really need to have a mainstream desktop microkernel operating system because:
1. no need anymore for kernel bypass mechanisms (too many to name for linux, btw)
2. decoupling of drivers from the kernel
3. instead of waiting for a backport of a new syscall to an LTS kernel, something like that will be just part of your system's stdlib
4. extremely reduced need to reboot a machine
5. driver faults can be recovered from gracefully, just like in Erlang's supervisor scheme
6. seL4's capability system allows for a safer system overall, with less hacks
Seeing how even Intel is introducing a message passing network with growing number of cores in their mainstream CPU designs, we should be over the general objections regarding a message passing design. They call it QMD, and it's something they already have in their Xeon Phi line for some time for obvious reasons, just as countless other general purpose or special purpose chip designs have had for a long time.
I wonder if one could get funding for an effort like Robigalia to reach production quality and have Servo running on it. Given the feature set of Servo, it's a safe bet that the required features would provide a reasonably complete system to replace your Linux machine.
The bigger struggle would be getting hardware vendors to contribute to FreeBSD and Linux drivers to also provide some level of support for a non-C code base. Though, moving up to that abstraction and language level should make it easier to write working hardware drivers.
> I wonder if one could get funding for an effort like Robigalia to reach production quality and have Servo running on it. Given the feature set of Servo, it's a safe bet that the required features would provide a reasonably complete system to replace your Linux machine.
If I got funding, Robigalia would definitely progress at least 10x faster than it does currently :) If anyone is interested in that, email me: corey@octayn.net...
As an aside, Robigalia has been picking up steam. The first developer preview should be out by Robigalia 2017 (April 25). Design documents and prototypes should be out by December 26 (the project's anniversary).
Oh, and if you extend it with multi-kernel functionality, scaling to very large number of cores/chips will also be solved in a fundamentally cleaner way. I haven't looked into it but there's an seL4 branch that implements multi-kernel support. If you don't know what this is, it's simply a way to have one kernel instance per processor, making scalability easier. Fujitsu has a linux variant to achieve the same and I think it's a goal of Barrelfish as well. Similar solutions exist in certain linux and dragonflybsd subsystems where, say, the network stack uses one scheduler or queue per core, removing the need for synchronization in a coarse way. Then, of course, you have to be smarter about scheduling things, but if you bind certain hardware bits to cores long-term, it should avoid accidental overhead via random migration. Language runtime VMs do the same for green threads with job stealing designs and pinning schedulers to cores. None of it is bleeding edge research material, we just have to use what's been invented.
I'm not sure that you need a kernel per-core. However, it would be nice for the microkernel to provide reliably per-cpu data structures to userspace. For example, via per-cpu replicated receive capabilities. That way, a capability send request from a client program would get routed to the same CPU's capability in the server. That would provide some very cache-friendly superfast machine-local IPC.
Completely eliminating shared-memory multiprocessing in userspace seems like a non-starter to me. Message passing is great, but there are plenty of cases where it's slower by many orders of magnitude. A good example is sparse matrix solvers; there's no way to get any kind of acceptable performance if you can't share the underlying data.
* Fuchsia is C (for the actual microkernel) and C++ (for userspace) / Redox is Rust.
* Fuchsia's main current target is smartphones & laptops / Redox' main current target is Rust.
* Fuchsia is very much funded / Redox is pretty grassroot.
* Fuchsia supports any language for app development but favors Dart / Redox supports any language for app developent but favors Rust.
Keep in mind that both projects are pretty young and that my points above involve some dose of mind-reading, so caveat lector.
Do you know of an icon set conversion of those that would work with gtk3? Even most icon themes that work with gtk2 are incorrectly structured for gtk3, with wrong icons display for, say, +/- controls. Using the ugly Adwaita set because it's the only complete and working one. The Haiku icon set also only works with gtk2.
