Re: Pull request denied
unlikely; or at least I have given up hope.
Ironically, considering the title of this article, he actually once said "people who are easily offended, should be offended".
133 posts • joined 30 Aug 2008
With a government agency, "monetise" is not the main worry. It's "discriminate", "victimise", "marginalise", and several other things.
And I don't mean just "Big Brother ((C) George Orwell) Modi". I mean any government anywhere in the world, really, because that's what our world is looking like more and more.
That said, I agree with Raj in what he said about the NIC. Not sure about the other part though... sounds plausible, but then the google+apple API expressly prohibits it. What do they do that we are missing?
I have a 4 years old Samsung "J2-6" (if I remember the model number right). I just checked in the Messages app, and under "Multimedia Messages" I see "Auto retrieve" is off.
I'm pretty sure I would done that during a permisison sweep when I first got the phone, so granted, it may not be the default, but as it stands, I very much doubt this is "zero-click" for my phone.
And since I know *no one* who would send an MMS (with Whatsapp being near ubiquitous) if I did get one I would probably just delete it sight-unseen.
Now, if you can send this via Whatsapp... now that would be a story!
I've upvoted your post, because I agree with you. Mostly.
In reality though, not everyone who has "Phone Pe", "Google Pay", and similar payment apps have *internally* enabled the UPI interface, so I have several times found that what I have (the BHIM app, from NPCL -- National Payments Corp Ltd I think) does not help me pay certain merchants, and I had to resort to cash.
(I've always been a "cash" guy, always wary of digital surveillance, but my "cash preferred, Big Brother Modi stop watching what I am buying" attitude has taken a hit due to Covid-19)
So I clicked the link.
Every single one is "risk level: low" and "wild level: low".
Existence is moot if it does not propagate.
To be clear, we're not saying Linux is invincible. As someone else mentioned, Linux encompasses all the software that runs on it (at least in people's minds). The Equifax hackers who used Tomcat bugs (if memory serves me right) could easily have written it to *also* propagate, but server to server propagation of binary exploits is not that easy (other than via hacked JS that gets included in a "partner" site).
But a thriving virus ecosystem, with almost every single unmanaged computer probably hosting at least a few, likely more, viruses? Only in Windows
title says it all.
The percentage of transmission due to documents is probably not even measurable. Currency notes are much more likely, and despite being a hard-core "cash is king" person, I can see that would be an issue, but passport, drivers licenses, and so on? Forget it... this is just the government trying to tout a service that no privacy-minded, security-minded, person should even consider using.
I don't understand why your post was downvoted so many times. I was going to write pretty much what you wrote, albeit in different words.
Whether Perens was wrong or right would depend on the actual contract. After all, since payment is involved, there has to be *some* contract above and beyond the GPL (i.e., the GPL cannot be the only contract involved). As long as that contract does not impose restrictions on the software that the client *already has*, GPL is not violated anyway.
And whether Perens was right or wrong, it was clearly an *opinion*. OSS were foolish to take it to court, and got rightfully smacked down.
If you haven't pushed it to anyone yet, rebasing to fix minor issues is perfectly fine. There's no earthly reason not to clean up a commit series before pushing it to the world. In fact, a clean commit series helps the other guys understand what you did better (e.g., rather than seeing commit 9 with something that puzzles them, not realising that commit 13 has a 1-word change that resolves that puzzle with a "doh!", they see commit 9 all correct and proper, say "good", and move on to commit 10).
Rebasing something that's already pushed is, of course, very bad. But that's no reason to ban rebase completely, which -- even if this particular articles does not indicate, this "Hipp" person definitely implements in his "fossil" product.
I would love to be fly on the wall at that meeting.
If you look at his "git versus fossil" page, at https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki , you can see it won't be a useful conversation. Heck it might not even stay polite, though I hear the guy who wrote git is now much mellowed than in the old days ;-)
Maybe not in the interview/article referred here; I was going by my memory.
So I did some digging: here you go... "Rebase Considered Harmful" -- https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
Also, https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#devorg very proudly (my interpretation) says "There is no rebasing mechanism in Fossil, on purpose".
Believe me, this guy is not shy about his hatred of rebase :)
Preventing rebase on a published set of commits is one thing, denying it completely in private branches -- before they're published -- is quite another.
I do recall reading about this "fossil" a few years ago, and I do remember backing off and pretty much ignoring it after that when I saw that the lack of rebase was a point of pride for that author.
There are kinder, gentler, ways to prevent rebase on a server, such as running `git config --global receive.denyNonFastForwards true`, without throwing the baby out with the bathwater and preventing its use on developer-local clones.
I know Linus himself has (supposedly, allegedly, reportedly!) mellowed, but I very much like, and agree with his famous quote about offending people: “I like offending people, because I think people who get offended should be offended.”
I don't mean (and I don't think he meant) that it should be practiced at every opportunity, but I'm sure we all know people who deserve that applied to them.
I merely got an error like this:
[00007f5b20c156e0] avformat demux error: Could not open /home/ff/heap-over-flow.mp4: Unknown error 1094995529
Further, the same vlc window was responsive (for example I was able to open some *other* video file and ask it to play it, and it did).
I can't be sure but I believe I read something like that.
Maybe this is the starting point. Just show the guns for now, and if too many people resist, next time, *use* them. Target people who donate to the Democratic party (as this guy says he did) and who knows, that may dry up funds for the opposition.
There seems to be a slight confusion here between sudo and being at the console.
The Xorg bug discussed here requires you to be logged in AT the console. On my not-yet-updated-for-this-bug Fedora system, there is a pam configuration line (specifically, `auth required pam_console.so` in /etc/pam.d/xserver) that appears to be ensuring that you cannot run an X server unless you have control of one actual console (that's one of those things you get when you hit Ctrl-Alt-F2/F3 etc).
This has absolutely nothing to do with sudo.
(You actually can run this over ssh also, but only if you are *also* logged in at the console, so it comes to the same thing)
If you're on a typical single user system that is running only the GUI and you rarely go to one of the actual ttys for any reason -- probably the only way to affect you is if someone who knows *some* userid and password to your box, *and* has physical access, were to do that Ctrl-Alt-F2 thing, login, and then run this command.
Servers, mostly running headless, likewise -- you'd have to get into the server room, attach a keyboard and mouse, and do this.
All in all, a very big bug, but not terribly scary for most people.
> Some new crypto system outside the cryptographic mainstream is not what you want to count on for security
It's the bloody cryptographic mainstream that got us the Dual EC-DRBG backdoor and God knows how many more things like that. While I still have a lot of respect for NIST, stepping away and looking at independent cryptographers like Dan Bernstein is definitely a good idea.
In any case, Dan's stuff is no longer an outsider -- almost every crypto suite worth its salt (no pun intended) is implementing it. They're not doing it because they're fanboys either; there are solid reasons -- openness (often called "nothing up my sleeve" in crypto), implementation ease, side-channel resistance, etc.
> That not everyone knows one or two specific niche facts or procedures does not give you *any* information on their personal level of competence and understanding of computers and related issues.
Except when they try to *say* things like "bloat" and "it should stay a module" and "I sense another smackdown [from Linus Torvalds]", etc.
xkcd 386, since you're so fond of xkcd.
"In five years or so this may be worth considering"? Really? TLS had padding related issues several more years later, and I won't even bring up heartbleed. The (passive) passage of time does not indicate anything,
Hence why the "4000 lines -- easy to review" point that is being made here.
I am not a cryptographer, but I know enough, thank you. I still say this is pretty darn good, uses the right set of algorithms (I'll admit to being a Dan Bernstein fanboy), and -- while nothing is absolutely certain -- it's a darn sight more trustworthy than a lot of other code.
And from a practical point of view, it's almost trivial to setup compared to those.
The number of people who are confused about what WG currently is, and what it is trying to be... ouch.
Currently Wireguard is a DKMS module (see https://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support for what that is). Basically, it is "out of tree" and every time a new kernel is installed (like when you do a "apt upgrade" etc and a new one comes in), all DKMS based modules have to be recompiled. Usually on *your* computer. Which means, among other things, you need to install gcc and a whole bunch of other packages.
Getting it into the Linux tree means you don't have to do that anymore. **It will STILL be a module**, except it will be part of the kernel sources, and the compilation happens at the distro, not in your computer.
In particular, it is NOT bloating the kernel any more than it currently is, as a DKMS module, for people who do not use it.
Oh and by the way, I've been using it for a couple of months now and it's absolutely wonderful. I've had no problems of any kind -- so read all that faff about "this is not yet complete" as typical open source "under-promise". It definitely "over-delivers", as far as I am concerned.
> Last time I saw, over 130 million users are on Notes/Domino.
Not by choice.
Don't forget Notes client is the only mail client that acquired "sort by subject line" in... wait for it... 2006.
Eudora and Pegasus had it in pretty much from day one, if I am not mistaken.
Ever tried to view all headers in an email in Notes? A *tiny* window pops up and you can't expand it. You have to look for the headers you're interested in, within what -- if I recall -- is a 20x8 text window.
I've never used Outlook, but compared to Thunderbird (speaking only of the client UI and UX), there is NO comparison.
a blockchain is a bit more than a linked list; it's a linked list with a cryptographic hash that makes it difficult to modify old blocks.
of course, version control systems like git (and even git got the idea from monotone, and maybe it's turtles all the way), have been doing this for years before "bitcoin", so I am in no way claiming that difference is new with blockchain!
I'm surprised no one mentioned IRC as an analogy. Much more sturdy than a web server.
And this is not, as the article says, a blockchain issue. This will only succeed if they join specific, already popular/widely used, blockchains (bitcoin and ethereum come to mind).
If they join some little known blockchain they may get blocked. In a way they're leveraging the somewhat implicit "too big to kill" nature of the big two blockchain instances.
"The internet treats censorship as damage, and routes around it". Wasn't that what people say?
I'd say China has found a way to break that. If you have to apply for a permit to serve port 80 or 443, and you don't get root on a machine you have at least rented, the amount of "routing around" you can do is pretty damn limited!
I think all wannabe totalitarians (and I am not excluding India's Aadhaar-crazed government here, and the USA was anyway only a democracy in name for some time) taking a good look and thinking... hmm, if China can do it, why can't I?
I wonder if, in about 20 years or so, all of the dystopian fantasies of Richard Stallman and Cory Doctorow would have come true.
People keep saying "turn off HTML".
You don't need to do that. You only need to turn off remote image loading.
In Thunderbird, this is called "Show Remote Content", and defaults to "no".
I looked at the EFF site as well as the "branded/logo-ed" site for this vuln, and could find no sign of this particular aspect, which makes it a non-issue for most TB users (and I'm willing to bet most other mail clients too).
You're confusing blockchain with proof of work.
Bitcoin == blockchain PLUS proof of work, but you can have blockchains which don't use proof of work as a consensus mechanism.
You must be a prof in a university somewhere -- that's all they care about, permissionless blockchains and crypto currency. After all, wilful ignorance of scaling limitations (to use a phrase from one of the previous comments) gives you more opportunities to publish.
If by "stored on my PC" you mean on disk, that's not relevant. If you've logged on to paypal or your bank in one tab, and to a dodgy site in another, it would be possible to extract those creds, in theory.
Even if you logged out, and *then* went to the dodgy site, if the browser didn't zero out the locations where it kept your password in memory, something could be extracted.
I'm not saying it's easy or practical but as they say, "attacks only get better".
> neither Meltdown or Spectre is much of a threat to a home user
No idea about Chrome, and even less about IE.
Biting the hand that feeds IT © 1998–2020