Slashdot Mirror

Downloaded Microsoft's proprietary, heavily restricted build of this editor which Microsoft suggests is an editor for wlinux. WTF? Doesn't run in text mode. But wlinux is text mode only. WTF.

And this is written in javascript. Again. WTF? Takes a full second to start up. Seriously, WTF?

Is this what it's always like in Microsoft land? I don't miss it a bit.

I got one or free (iPad mini) from the company where I worked. It is a nice portablescreen, but terrible if you need to do any data input. So I hardly ever use it.

I also have a similar sized portable with a detachable keyboard. When I use it, I never detach the keybard and never use the touchscreen. The size is just good enough to do what I do on my phone.

A 14" or 15" portable is much better to do anything on it, even if it is just browsing or email or watching movies. It also has a buil-in stand to hold the screen in a position I can watch it.

So I now ahave a 14" HPO Chromebook. With Crouton I run Debian and as an extra bonus when I am at the border and the person taps Space instead of CTRL-D, it deletes the Debian part. Nice.

I also have a 17" portable for if I need to do actual work when I am not home.

the vibrant iOS Open Source community

You've got some private definition of "vibrant". Apple open source looks about as vibrant as code.google.com.

Bullshit.

This GitHub Repository shows 847 Projects.

https://github.com/dkhamsing/o...

And there are several more that are Swift-Specific.

I've never seen pong using qt or gtk, but there is always: https://github.com/kurehajime/...

I'm confused. iOS is OS X. I can compile the same code base for both systems with the press of a button.

There is lots of Open Source software already running on iOS:
https://github.com/dkhamsing/o...

If a full blown Unix like programming environment with full support for C and C++ isn't enough, xamarin is there and provides "Single shared codebase for Android, iOS, and Windows" available under the MIT license.
https://visualstudio.microsoft...

There is also no requirement to use Apple's App Store as long as you have physical access to a device and a free developer account. I expect most people who want to build and develop open source will probably have physical access to an iOS device if they want one.

The wing-nuts specifically want equity over equality. That is, they don't want equality of opportunity, they want equality of outcome. That post is also a perfect example of the Motte and Bailey strategy. The first part is the actual goal, the bailey. Inequal treatment in their favor. The second part is what they defend, the motte, which looks entirely reasonable. They are also against meritocracy. It is horrific. I can't believe that this got into the linux kernel and that people are standing by this sort of drivel.

But people get swept up in movements. It becomes a tribalism thing of us vs them. You know it's a bad witch-hunt when any call for moderation gets you labeled as a witch. Democrats need to self-police and protest the protection and acceptance of these sort of hate-filled racist and sexist bigots. Otherwise our party is going to get as crazy as the TEA-partiers.

(But Cosby is black. You too also need to tone down the racist rhetoric)

The shit-o-meter is how many up-votes the dissenting reply gets.

...which implies for every loon, every conspiracy theory, every fake news, every thinly disguised bigotry, and other bullshit, you'll need somebody to respond with a non-trivial reply, lest those posts remain unchallenged.

This is not a battle you'll win. The side with no regards to facts or logic has the advantage in asymmetrical warfare, churning out noise faster than you can type up rebuttals.

Often on Twitter the best posts are replies

Only replies that confirm your biases. Replies that don't but get highly rated? Oh surly that must be the work of Russian bots and alt-right fanboys!

And this assumes people wouldn't enact block lists (like https://github.com/freebsdgirl...) and ignore any replies from certain people, no matter how reasonable their replies might be

No, not because user space programs would be considered derived works (aka being 'infected' by GPL) but because the header files must be included to make proprietary non-GPL'd programs that run under Linux ... so they can't be strictly GPL.

The User-space API (UAPI) header files, which describe the interface of user-space programs to the kernel are a special case. According to the note in the kernel COPYING file, the syscall interface is a clear boundary, which does not extend the GPL requirements to any software which uses it to communicate with the kernel. Because the UAPI headers must be includable into any source files which create an executable running on the Linux kernel, the exception must be documented by a special license expression.

Linux itself won't be GPLv3 and it isn't even GPLv2, free software advocates cling to it but it has a very explicit exception to the GPLv2 which prevents that license from infecting programs that link to the kernel for syscall purposes.

This is misleading - the Linux kernel itself is under GPL2 with no modifications.

But with exceptions as clearly stated here.

The 'syscall exception' just specifies that user-space programs using normal Linux syscalls are NOT derivative works, and therefore not subject to the terms of the GPL.

Yes and the reason for this is because if the license were GPLv2, without this exception, then user space programs making syscalls would be considered derived works and subject to the terms of the GPLv2 as well.

If I licensed a program under GPLv2 and put in an exception for all the distribution clauses would you still consider it to be a GPLv2-licensed program? No reasonable person would.

Although in this case the person responsible seems to be Patrik Flykt, who added the code with this commit about 4 years ago: https://github.com/systemd/sys...

Poettering committed the fix.

I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?

tmpfiles: R! /dir/.* destroys root

Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.

So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid.

systemd can't handle the process previlege that belongs to user name startswith number, such as 0day

I tested Ubuntu, Debian, FreeBSD, and OpenSolaris, 0day is a perfectly valid username.

How did anyone that lacked that much understanding about UNIX get in charge of the init system?

I am not sure I'd consider this much of a problem. Yeah, it's a UNIX pitfall, but "rm -rf /foo/.*" will work the exact same way, no?

tmpfiles: R! /dir/.* destroys root

Yes, as you found out "0day" is not a valid username. I wonder which tool permitted you to create it in the first place. Note that not permitting numeric first characters is done on purpose: to avoid ambiguities between numeric UID and textual user names.

So, yeah, I don't think there's anything to fix in systemd here. I understand this is annoying, but still: the username is clearly not valid.

systemd can't handle the process previlege that belongs to user name startswith number, such as 0day

I tested Ubuntu, Debian, FreeBSD, and OpenSolaris, 0day is a perfectly valid username.

How did anyone that lacked that much understanding about UNIX get in charge of the init system?

If kids are interested in programming, just point them at https://codecombat.com/
Kids that will be natural programmers won't even need a teacher to play
If SJWs want more girls in programming, they should fork https://github.com/codecombat/... and make a version that is more appealing to young girls.

Here's how I like 'em...and I suggest ya have 'em the same way! (sorry about the jumbled wall of text, Slashdot would not accept it when it was neatly formatted)

OS: LineageOS (XDA Forums), Activity tracker: Loop Habit Tracker, Ad blocker: AdAway, Appstore: F-Droid & Yalp Store, Audiobook player: Voice, Calculator: LineageOS stock or Simple Calculator, Calendar: Simple Calendar (Offline, local calendar), Camera: LineageOS stock or Simple Camera, Clock: Simple Clock or LineageOS stock, Contacts: Simple Contacts or LineageOS stock, Document scanner: Open Note Scanner, Document viewer: Document Viewer, Drawing: Simple Draw, Email: K-9 Mail, Feed reader: Flym, File Manager: Simple File Manager and DiskUsage, Game: Shortyz & SolitaireCG, Gallery: Simple Gallery or LineageOS stock, Launcher: LineageOS stock, Loyalty card: Loyalty Card Keychain, Maps: OsmAnd+, Messenger: Delta Chat and Meshenger, Music player: Simple Music Player or Vanilla Music or LineageOS stock, Netcast client: SoundWaves or AntennaPod, Notes: Simple Notes, Password manager: KeePassDroid, Sensor test: Sensor Readout, SMS: Silence, Spirit level: Bubble, Star chart: Sky Map, Television killer: TV KILL, Terminal emulator: Termux, Unit converter: Unit Converter Ultimate, Web browser: Private Browser or

No, it was disclosed outright on Twitter/Github.

https://github.com/SandboxEsca...

Applause to IBM opensource-ing their mac config recipes but is the recipes only. Appears to me that the actual runtime that executes and applies the config recipes is commercial proprietary config management & deployment suite called Jamf Pro.
See https://www.jamf.com/products/jamf-pro/
and https://github.com/IBM/mac-ibm-enrollment-app/

In light of config management via actual FOSS runtimes (Puppet/Chef/Ansible/Salt), this seems like a thinly veiled advert for Jamf Pro.

Having a CoC is protective coloration, you do it to avoid trouble whether you believe in it or not.

That's why all of the mainstream CoCs don't allow any discrimination against anyone for any reason, including experience level. (You ageist bastards who think 1 year post college almost certainly doesn't qualify you to maintain a kernel subsystem and arbitrate patching disputes can fuck right off and die as the SJWs say)

I mean look at the Spotify CoC which openly says clearly that if you're a super-marginalized person (gay, transgendered, multi-racial, non-binary voodoo practitioner for example) you can shit all over the carpet and those evil normies can fuck right off and die:

Our open source community prioritizes marginalized people’s safety over privileged people’s comfort. We will not act on complaints regarding:

        ‘Reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’ and ‘cisphobia’

        Reasonable communication of boundaries, such as “leave me alone,” “go away,” or “I’m not discussing this with you”

        Refusal to explain or debate social justice concepts

        Communicating in a ‘tone’ you don’t find congenial

        Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or assumptions

Huh, it would strongly appear that as long as you're a SJW blessed entity you can pretty much get away with murder while if you're one of the evil non-SJW classes you will be ignored and are a fair target for any kind of harassment, abuse or anything else so long as one cloaks it in SJW non-sense.

Yeah, and people wonder why lots of other people look at CoCs as nothing but political correctness bullshit

Having a CoC is protective coloration, you do it to avoid trouble whether you believe in it or not.

That's why all of the mainstream CoCs don't allow any discrimination against anyone for any reason, including experience level. (You ageist bastards who think 1 year post college almost certainly doesn't qualify you to maintain a kernel subsystem and arbitrate patching disputes can fuck right off and die as the SJWs say)

I mean look at the Spotify CoC which openly says clearly that if you're a super-marginalized person (gay, transgendered, multi-racial, non-binary voodoo practitioner for example) you can shit all over the carpet and those evil normies can fuck right off and die:

Our open source community prioritizes marginalized people’s safety over privileged people’s comfort. We will not act on complaints regarding:

        ‘Reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’ and ‘cisphobia’
        Reasonable communication of boundaries, such as “leave me alone,” “go away,” or “I’m not discussing this with you”
        Refusal to explain or debate social justice concepts
        Communicating in a ‘tone’ you don’t find congenial
        Criticizing racist, sexist, cissexist, or otherwise oppressive behavior or assumptions

Welcome to 2018.

The days of pulling the "Everyone I disagree with is an alt-right manbaby facist nazi sexist homophobe" are long gone.

People can and have seen for themselves the attacks on innocent open source developers:

https://github.com/opal/opal/i...

Dumb, lactose99, very, very dumb.

A possible clue:

Moving to bare metal and federated storage on Rackspace has brought our average Rails response time to consistently under 100ms

But that post is ancient.

I've wrote a comment with some background information on Hacker News: https://news.ycombinator.com/i...

Copying the content here for ease-of-use:

The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component.

To give you some context on how this could happen:

• As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file
• Over time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production
• I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured.
• Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQu...
• The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it
• The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQu...

Looking back, there are a couple of things that I should have done differently:

• Move out the server-side components into separate repositories
• Inform users better about file upload security - see https://github.com/blueimp/jQu...
• Never assume people actually read information about security
• Never rely on .htaccess for security configurations in Apache
• Make sure that published code is secure in all default configurations
• Never allow all file types for upload by default, even if it is secure in your configuration
• Recommend users to not upload files in the same root as their executable web application
• Always follow security best practices, even if it makes setup for users more difficult

I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other.

Bonus info:

• The client-side component had a cross-site scripting vulnerability in the Iframe Transport HTML site back in 2012: https://github.com/blueimp/jQu...
• The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQu...

I've wrote a comment with some background information on Hacker News: https://news.ycombinator.com/i...

Copying the content here for ease-of-use:

The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component.

To give you some context on how this could happen:

• As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file
• Over time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production
• I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured.
• Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQu...
• The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it
• The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQu...

Looking back, there are a couple of things that I should have done differently:

• Move out the server-side components into separate repositories
• Inform users better about file upload security - see https://github.com/blueimp/jQu...
• Never assume people actually read information about security
• Never rely on .htaccess for security configurations in Apache
• Make sure that published code is secure in all default configurations
• Never allow all file types for upload by default, even if it is secure in your configuration
• Recommend users to not upload files in the same root as their executable web application
• Always follow security best practices, even if it makes setup for users more difficult

I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other.

Bonus info:

• The client-side component had a cross-site scripting vulnerability in the Iframe Transport HTML site back in 2012: https://github.com/blueimp/jQu...
• The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQu...

I've wrote a comment with some background information on Hacker News: https://news.ycombinator.com/i...

Copying the content here for ease-of-use:

The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component.

To give you some context on how this could happen:

• As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file
• Over time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production
• I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured.
• Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQu...
• The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it
• The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQu...

Looking back, there are a couple of things that I should have done differently:

• Move out the server-side components into separate repositories
• Inform users better about file upload security - see https://github.com/blueimp/jQu...
• Never assume people actually read information about security
• Never rely on .htaccess for security configurations in Apache
• Make sure that published code is secure in all default configurations
• Never allow all file types for upload by default, even if it is secure in your configuration
• Recommend users to not upload files in the same root as their executable web application
• Always follow security best practices, even if it makes setup for users more difficult

I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other.

Bonus info:

• The client-side component had a cross-site scripting vulnerability in the Iframe Transport HTML site back in 2012: https://github.com/blueimp/jQu...
• The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQu...

I've wrote a comment with some background information on Hacker News: https://news.ycombinator.com/i...

Copying the content here for ease-of-use:

The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component.

To give you some context on how this could happen:

• As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file
• Over time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production
• I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured.
• Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQu...
• The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it
• The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQu...

Looking back, there are a couple of things that I should have done differently:

• Move out the server-side components into separate repositories
• Inform users better about file upload security - see https://github.com/blueimp/jQu...
• Never assume people actually read information about security
• Never rely on .htaccess for security configurations in Apache
• Make sure that published code is secure in all default configurations
• Never allow all file types for upload by default, even if it is secure in your configuration
• Recommend users to not upload files in the same root as their executable web application
• Always follow security best practices, even if it makes setup for users more difficult

I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other.

Bonus info:

• The client-side component had a cross-site scripting vulnerability in the Iframe Transport HTML site back in 2012: https://github.com/blueimp/jQu...
• The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQu...

I've wrote a comment with some background information on Hacker News: https://news.ycombinator.com/i...

Copying the content here for ease-of-use:

The vulnerability is a combination of Apache v.2.3.9's default setting to not read .htaccess files and my mistake of relying on .htaccess to enforce security of the sample PHP upload component.

To give you some context on how this could happen:

• As the project name implies, this started as a client-side jQuery plugin, with a dummy PHP script to echo out the uploaded file
• Over time, I added a couple of sample server-side upload components, including two for Google App Engine (Python + Golang) - which I used for the demo - and one for PHP, which I never used myself in production
• I used the PHP component for local tests with various possible file uploads, including very large files and chunked uploads, which required enabling all file types for upload. My thinking was that allowing all file types for upload is not critical as long as the handling of those files is properly configured.
• Prior to adding the .htaccess file, I mistakenly assumed developers would configure their Apache server themselves so that no PHP scripts would be executed in the uploads folder. It was only added in this commit: https://github.com/blueimp/jQu...
• The Apache servers I tested with always had support for .htaccess enabled, so I never bothered to check that the default Apache configuration since version 2.3.9 actually disabled it
• The original .htaccess configuration didn't even prevent script execution in all Apache configurations and had to be fixed, see: https://github.com/blueimp/jQu...

Looking back, there are a couple of things that I should have done differently:

• Move out the server-side components into separate repositories
• Inform users better about file upload security - see https://github.com/blueimp/jQu...
• Never assume people actually read information about security
• Never rely on .htaccess for security configurations in Apache
• Make sure that published code is secure in all default configurations
• Never allow all file types for upload by default, even if it is secure in your configuration
• Recommend users to not upload files in the same root as their executable web application
• Always follow security best practices, even if it makes setup for users more difficult

I wanted to make it really simple for users to install a generic and secure file upload service with a great user interface. Unfortunately, security best practices and ease-of-use are often at odds to each other.

Bonus info:

• The client-side component had a cross-site scripting vulnerability in the Iframe Transport HTML site back in 2012: https://github.com/blueimp/jQu...
• The App Engine components had an open redirect vulnerability back in 2015: https://github.com/blueimp/jQu...

The worst part of this whole thing is that if you look at the patches, you'll see that one of the four links doesn't exist anymore, and 3/4 of the others just guard against NPE's by adding an if-statement.

Unfortunately, the last one listed also adds a this qualifier that would be a red-flag to any competent maintainer, because the patch would actually fail if there's a local variable by that name in the same scope (which could easily happen by accident in the future). Let's hope that the maintainer removed the this qualifier when merging the patch.

mps-youtube is delicious gold: it's a command-line interface for youtube-dl with plenty of fun options.

https://github.com/rapid7/meta...

def run
        # Registry key to manipulate
        reg_key = 'HKLM\\SAM\\SAM\\Domains\\Account\\Users'
          # Checks privileges of the session, and tries to get SYSTEM privileges if needed.
        print_status("Checking for SYSTEM privileges on session")
        unless(is_system?())
            if (datastore['GETSYSTEM'])
                print_status("Trying to get SYSTEM privileges")
                if get_system
                    print_good("Got SYSTEM privileges")
                else
                    print_error("Could not obtain SYSTEM privileges")
                    return
                end

This is the part everybody is talking about. You need root to get root. Not much of an exploit.

--Highdude702(mods)

Can we have a link to material that might verify this claim?

A search of "RID Hijacking" revealed (among other things) a commit to metaploit on Feb 20. (likely merged in from a fork)

Git commit dates can be faked so there is also an announcement from @BlackHatEvents about it from June 24.

I'm quite inclined to believe their claim.

Which service is relatively new and might have more open addresses.

I've read good things about ProtonMail. It's the service I've been considering myself, although I haven't committed yet.

How do I get my 50k emails OUT of gmail and the IN to the new service.

Gmail supports IMAP, so you can do that with any IMAP-capable desktop email client such as Thunderbird. Configure both accounts in the client and simply copy the emails by hand. In my experience it's better to do this in batches of 100 to 500 emails at a time.

If you'd like something more automated, you can write a small Python script using the OfflineIMAP module to first download you Gmail messages locally and then upload them to your new email provider. I used it years ago when the small business I worked for at the time switched email providers. It's pretty easy to do. I managed to write something that did the job in about half a day even though I didn't know Python at all at the time. It then took about five days for the 20 accounts or so to transfer. The few emails that didn't transfer failed because they had some malformed headers that the destination email provider disliked, so I had to fix those by hand before managing to successfully upload them too, which took one or two additional days.

Moving to ANY mail server (with IMAP) with your own domain would be the way to go. This guy's script works just fine to the transfer: http://oskarhane.com/transfer-... I personally use a setup that's fairly similar to mailcow: https://github.com/mailcow/mai...

As mentioned in another post, Audacious is the new iteration of XMMS. I remember moving from XMMS to Audacious in 2006, as I have a frontend for them I originally wrote in 2002 and continue to use.

Yes https://yro.slashdot.org/comme... & there's the proof quoting you in it bogusly "downmodbombing" my posts (no biggie - I can post w/ NO LIMITS unlike most Ac's so I override your PUNY "wannabe weapon" inevitably RUNNING YOU DRY of them, lol)

You say that like it's something to brag about. In reality, your post shows just how obsessed you are with Slashdot. It's evidence that you don't do anything worthwhile with the rest of your life, so you obsess over an internet forum.

You can make unlimited anonymous posts? That's what you want to brag about?

You can waste other people's time and mod points by posting lots of offtopic spam? That's what you want to brag about?

Oh, wait, you wrote a program that downloads other people's hosts files, concatenates them, sorts the resulting file, and removes duplicate entries? That's your big achievement? News flash: there are far superior open source alternatives available, that don't rely on untrusted binaries that haven't been digitally signed.

But because I care and I've noticed your posts becoming even more threatening and deranged than usual, I made a phone call to the New York State Police about you. Let's just say they're taking your threats seriously and the words "mandatory psychiatric evaluation" came up in the conversation. You might finally receive the mental health assistance you desperately need.

QWERTY are two things: A physical layout of keys in rows and a logical mapping of symbols to those keys. Dvorak is only the latter.

I think physical layout is much more important than the key mapping. I have a bit of RSI on the outer side of the hands (Emacs pinkie) and would like to reduce the stress on the pinkie. As a programmer I am probably biased but I don't find the layout of the letters to be problematic. I spend a lot more time thinking than typing so typing speed isn't a huge issue. I also spend more time navigating, editing or typing weird symbols like braces and brackets than I do typing plain English text and those actions are some of the least ergonomic. Most key maps like Dvorak or Colemak optimise key placement based on the typing of english text but do nothing for symbols or placement of modifier keys (shift, control, alt). Neo is the only one I know that remaps symbols and movement by creating more modifiers/layers but all the modifiers are still along the edge of the keyboard and pressed with the pinky (and it is in German).

I have tried some ergonomic keyboards but none have caught on either because they were not radical enough (just a qwerty split in half) or because they were too big, expensive or not laptop friendly. Actually, none are laptop friendly if you do type on your lap. Some of the single hand chorded keyboards could be laptop friendly enough but they would have to support all the various brackets and braces for general use.

To scratch my own itch, I have been experimenting with my own chorded shortcuts software which distinguishes between ordinary typing and when you're Holding one key and Press-Releasing another. It basically treats the key events "Press A - Press/Release B - Release A" as a shortcut which can be mapped to anything. It helps with my particular case of RSI since I can remap all modifiers to the strong fingers (hold V or M for Ctrl, F and J for Shift, hold Space for movement and deletions etc). It works rather well but I do occasionally get some false positives so it isn't perfect yet. The code is here ( https://github.com/hopr/hopr ) if anyone is interested but it is a prototype without any polish since I am the only user. It works for me though.

I would very much like a redesigned keyboard with all movement, editing and modifier keys moved to the bottom (thumb) or center (index finger) but I want it on both laptops and desktops. Laptops won't change anytime soon so I think we are stuck with QWERTY. A more radical remapping of the qwerty keyboard would be interesting (like use all inner keys FGHJ etc as layers/modifiers like Neo) but only for some special groups like programmers or people with RSI. Neurological implants would of course be cool but so would magic wands.

There should really be a universally interoperational social networking platform standard that isn't controlled by any single corporation or country.

Sir Timothy John Berners-Lee OM KBE FRS FREng FRSA FBCS just launched such a platform standard:
- https://www.inrupt.com/blog/one-small-step-for-the-web
- https://solid.inrupt.com/
- https://github.com/solid/userguide
- https://tech.slashdot.org/story/18/09/30/1122238/tim-berners-lee-announces-solid-an-open-source-project-which-would-aim-to-decentralize-the-web

Captcha: unionize

To be fair, two of those links go to DataFixerUpper, where the code author actually impelmented Profunctor Optics in fucking Java. That's category theory type stuff that's usually found in pure FP languages like Haskell; props to the guy that did that, because manually implementing that in Java is both twisted and very impressive.

(From what I read elsewhere, it was the work of the Forge dev that Mojang hired, rather than the original crew.)

*clears throat*

There is a good selection of content - in the form of mods (at least a few hundred, but I can't give you an exact count), mod packs, texture packs, and what we call "sub-games", which can be anything from minor changes to a complete overhaul of the game play.

All mods/modpacks are open source, written in Lua. The engine supports acceleration via LuaJIT, and the modding API can be enhanced/expanded with libraries such as luasocket (for example, IRC for command and control, or to link several servers' chats together via a common #channel). Most mods are true FOSS, but the exact licenses naturally vary by author.

Mods run on the server (or server-process); a basic client modding API is present as well, which individual players may take advantage of if they want. Such mods are installed by the player, and only alter their client's behavior - what one player has installed has no appreciable effect on anyone else or on the server (or that's the intent of client-supplied mods anyway). Server-supplied client mods are on the engine road map. Unlike MC, players do not have to mod their clients to match a server's mods, and they are free to install any mods they want for their own, single-player use, regardless of what their favorite servers have.

If you can think of it, there's a good chance a mod exists to supply it, except that our mods can't change the engine or shaders (there's generally no need to do so in the former case, and the latter is currently a controversial topic).

There's a good selection of public game servers as well. Couple hundred at the moment on the public list (the number varies), plus however many private/unlisted ones there are.

Servers (or single-player mode) can operate in creative or survival mode, and the latter can be anywhere from easy to hardcore. Hybrid operation is possible too (i.e. some level of survival, with creative rights given to selected individuals, as the admin sees fit).

The standard Minetest package comes with a command-line server application, plus the client can be used to host a server from one of the user's local worlds (using whatever mods that world is configured to use).

The client features an in-game mini-map, and external utilities exist to generate large overviews, even interactive pan/zoom maps, such as this one on my website.

Both the engine core and the default game content (which is itself a sub-game) are under active development, though the developers would surely appreciate more contributions.

Get it from the official website or get the engine source from the official Github repository. The default sub-game comes with the package on the Minetest website, or get it from its official Github repository. Note: on both repos, the "master" branch is "unstable" development leading up to 5.0.0. Visitors will probably want the "stable-0.4" branch. Oh, and no, that's not a typo - the version scheme changed after the 0.4 series, to drop that leading zero.

Android and iOS clients exist, too, but I make no recommendations one way or another on those.

We also have an active discussion forum, which also serves as a prominent place to release new content. There's also the official Minetest content database, another place new content can be released.

Full disclosure: I'm a prominent member of the Minetest community: modder, texture pack author, and server operator (two easy survival, two creative, one nostalgic, plus a couple that I host for friends). So I'm a little biased. :-)

Note: if someone tells you to use some links other than what I gave above, disregard that person's links and claims.

*clears throat*

There is a good selection of content - in the form of mods (at least a few hundred, but I can't give you an exact count), mod packs, texture packs, and what we call "sub-games", which can be anything from minor changes to a complete overhaul of the game play.

All mods/modpacks are open source, written in Lua. The engine supports acceleration via LuaJIT, and the modding API can be enhanced/expanded with libraries such as luasocket (for example, IRC for command and control, or to link several servers' chats together via a common #channel). Most mods are true FOSS, but the exact licenses naturally vary by author.

Mods run on the server (or server-process); a basic client modding API is present as well, which individual players may take advantage of if they want. Such mods are installed by the player, and only alter their client's behavior - what one player has installed has no appreciable effect on anyone else or on the server (or that's the intent of client-supplied mods anyway). Server-supplied client mods are on the engine road map. Unlike MC, players do not have to mod their clients to match a server's mods, and they are free to install any mods they want for their own, single-player use, regardless of what their favorite servers have.

If you can think of it, there's a good chance a mod exists to supply it, except that our mods can't change the engine or shaders (there's generally no need to do so in the former case, and the latter is currently a controversial topic).

There's a good selection of public game servers as well. Couple hundred at the moment on the public list (the number varies), plus however many private/unlisted ones there are.

Servers (or single-player mode) can operate in creative or survival mode, and the latter can be anywhere from easy to hardcore. Hybrid operation is possible too (i.e. some level of survival, with creative rights given to selected individuals, as the admin sees fit).

The standard Minetest package comes with a command-line server application, plus the client can be used to host a server from one of the user's local worlds (using whatever mods that world is configured to use).

The client features an in-game mini-map, and external utilities exist to generate large overviews, even interactive pan/zoom maps, such as this one on my website.

Both the engine core and the default game content (which is itself a sub-game) are under active development, though the developers would surely appreciate more contributions.

Get it from the official website or get the engine source from the official Github repository. The default sub-game comes with the package on the Minetest website, or get it from its official Github repository. Note: on both repos, the "master" branch is "unstable" development leading up to 5.0.0. Visitors will probably want the "stable-0.4" branch. Oh, and no, that's not a typo - the version scheme changed after the 0.4 series, to drop that leading zero.

Android and iOS clients exist, too, but I make no recommendations one way or another on those.

We also have an active discussion forum, which also serves as a prominent place to release new content. There's also the official Minetest content database, another place new content can be released.

Full disclosure: I'm a prominent member of the Minetest community: modder, texture pack author, and server operator (two easy survival, two creative, one nostalgic, plus a couple that I host for friends). So I'm a little biased. :-)

Note: if someone tells you to use some links other than what I gave above, disregard that person's links and claims.

Always wondered how binary blobs are even legal with the GPLv2

Because the kernel isn't GPLv2, it's often lauded as the biggest success story of the GPL but in fact it has a very specific exception which would otherwise put any software with an incompatible license making syscalls to the kernel in violation of the GPL.

This is one of the things that has led to the Linux kernel being so successful.

These code bases have a serious issue with readability and maintainability. They seem to frequently write massive methods with deep nesting, and not even leaving some API or class documentation for posterity.

It's the kind of gobbledygook code that I only see from freshly-graduated programmers and in competitive coding puzzles. Mojang should spend a few days to set up some static code analyzing tool like SonarQube.

These code bases have a serious issue with readability and maintainability. They seem to frequently write massive methods with deep nesting, and not even leaving some API or class documentation for posterity.

It's the kind of gobbledygook code that I only see from freshly-graduated programmers and in competitive coding puzzles. Mojang should spend a few days to set up some static code analyzing tool like SonarQube.

These code bases have a serious issue with readability and maintainability. They seem to frequently write massive methods with deep nesting, and not even leaving some API or class documentation for posterity.

It's the kind of gobbledygook code that I only see from freshly-graduated programmers and in competitive coding puzzles. Mojang should spend a few days to set up some static code analyzing tool like SonarQube.

These code bases have a serious issue with readability and maintainability. They seem to frequently write massive methods with deep nesting, and not even leaving some API or class documentation for posterity.

It's the kind of gobbledygook code that I only see from freshly-graduated programmers and in competitive coding puzzles. Mojang should spend a few days to set up some static code analyzing tool like SonarQube.

These code bases have a serious issue with readability and maintainability. They seem to frequently write massive methods with deep nesting, and not even leaving some API or class documentation for posterity.

It's the kind of gobbledygook code that I only see from freshly-graduated programmers and in competitive coding puzzles. Mojang should spend a few days to set up some static code analyzing tool like SonarQube.

kdbus hasn't been an issue for at least 3 years, everyone is focusing on improving the userspace implementations of the DBus protocol.

But do go on, keep demonstrating that the anti-systemd side is mostly composed of idiots. The more you do your best, the sooner we can write you lot off as irrelevant.

It's not "completely free" because it's not open-source.

Krita is completely free and open. Don't know why you would think otherwise.

Most of the spyware was backported to 7 and 8.1. Conveniently MS now only provides monthly update rollups in which you cannot choose which parts to install instead of many separate patches like in the past.

That's true, but at least on 7 and 8 you can still remove it after installation, e.g. with remove_crw.cmd. With Windows 10, it is baked in.

Here you go: https://github.com/xiph/rav1e

Ok so you mean this? https://github.com/dotnet/core

In particular, the example workflow implies that dyn-reg support is mandatory, at least for RPs. (I'm assuming for the moment that "must" means "MUST" in the RFC 2119 sense.)

If this is the first time a Provider and a Relying Party are encountering each other, the RP must perform Dynamic Client Registration. Note: This is an operation that happens under the hood, and does not involve the user. All compliant OIDC clients have this functionality built in.

But it doesn't technically make dyn-reg mandatory for providers.