>Free software
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
>Free software
>>53014954
FUCK! I'm downloading Windows 10 while I can! Then I build muh own toilet!
>wget google.com
kek'd
>>53014954
>GNU
Garbage software, not surprised.
>>53014954
Yes, because
>Internet core building blocks
is something you'll never see in a sentence with Windows.
Daily reminder this would never happen with proprietary software like windows or Mac
>over 7 hours to compile and its a piece of shit
Sasuga GNU.
FURTHER READING:
WHY you should UPGRADE to MICROSOFT™ WINDOWS 10™: An objective and totally non-biased analysis
>>53015393
>http://arstechnica.com/security/2016/02/extremely-severe-bug-leaves-dizzying-number-of-apps-and-devices-vulnerable/
Android Google NSA just werkz. Shill moar cellphones, ni/g/s!
>>53015429
>One Linux-based package that's not vulnerable is Google's Android mobile operating system. It uses a glibc substitute known as Bionic and isn't susceptible, a company representative said.
Google NSA, it juest WERKZ.
>>53015320
wget google
>downloads entire interweb
>>53015346
It does, it's just that here you find out about it, instead of it being swept under the rug in some "no, you don't even get patch notes" Windows Update package.
I didn't see an update for glib today, have they fixed this a while ago or is it still a problem?
>l-linux b-btfo!
>it's a gnu problem
>>53016095
Download Android, only loonix not affected.
>>53014954
>GNU
okaaay, now y'all're starting to call GNU GNU and not Linux
when it works, it's Linux
but just one tiny little problem shows up once, and it's not Linux anymore
not even GNU Linux
just GNU
okaaaaay
>>53015346
Shitty b8, m80
>>53014954
Here is your patch you tech illiterate piece of shit.
Look up your shit before shitposting like a true underage winbabby
https://sourceware.org/ml/libc-alpha/2016-02/msg00416.html
>>53015901
Why did no one download google and became their concurrent?
Dude I'm going to become a billionaire
>>53015346
>>53014954
The recent GNU bashing on /g/ was a sign of things to come.
I read about this earlier today, holy mother fuck how that article is so dramatic about it like it's the end of the world
From what I remember it only affected programs that used some copy function
HURRR DURR THOUSANDS OF DEVICES!! CORE INTERNET BLOCKS!! ITS Y2K ALL OVER AGAIN!! why do you read this trash?
>>53017043
It is quite serious. The news is sensationalizing everything as usual but this is still a pretty embarrassing exploit.
>>53017034
Fake
GNU has linux, there is no argument
>>53016795
>okaaay, now y'all're starting to call GNU GNU and not Linux
>when it works, it's Linux
>but just one tiny little problem shows up once, and it's not Linux anymore
>not even GNU Linux
>just GNU
But that's valid. You don't need GNU to run Linux, you can use busybox and the musl lib C.
>>53016095
My Debian home server had an update today. It's on the Debian website too. My RasPi with Raspbian hasn't gotten it yet though.
>>53016917
/thread
Debian and RHEL are already patched.
>>53017064
It's a fucking buffer overflow ffs.
>>53016917
/thread
you all can leave now, there's no point in posting in this shitty bait thread anymore
>>53017166
>>53016917
It went unpatched for years, though :^)
OPEN SORES!!!!!
>>53017289
>It went unpatched for years, though :^)
Yes, windows doesn't have exploits, like the scroll bar one for instance.
>>53017289
>B-BUT
It's patched now. Fuck off.
>>53017300
>thinking closed sores software written by indians is any better than open sores software written by big tech companies, along with some independent people and basement dwellers
>>53017289
Do you know what zero day means? It's people like you that makes the whole windows userbase in /g/ look like children
>takes freetards 8 years to patch a buffer overflow
Almost choked on my curry with great laughter!
>>53016917
Did this patch get pushed automatically and involuntarily?
>>53017339
Found another one
Why do you even pretend to know what you are talking about?
>>53017339
>Rajeesh Patel
that explains why there's so many winshits all over /g/
>>53017339
>Almost choked on my curry with great laughter!
Yes, indianshit. It went unnoticed because it was only found recently. It's called a 0-day, tech illiterate.
>>53016917
Yeah, good luck getting that patch out to every internet facing linux box deployed in the last 8 years.
It's the server admins fault it wont happen but unfortunately that's reality.
>>53017373
Freetards on damage control
>>53017387
>internet facing linux box deployed in the last 8 years
Read about the exploit, retard. It's a buffer overflow and it only affects a small subset of programs.
>>53017387
Wow, get a load of this retard
See >>53017178
>>53015346
I remember in 2006 when probooks had an exploit in their battery voltage controllers which had passwords to the regulator for the voltage was all default. This basically meant all you had to google was the developer of the microcontroller and the default password for it. Someone wrote a virus for Macs and it basically overvolted the battery via this microcontroller and caused probooks to effectively burst into flames
>>53017404
>Freetards on damage control
Not even mad, I use musl libc. Fuck GNUshit.
>>53017404
Seriously, stop embarassing yourself
https://en.wikipedia.org/wiki/Zero-day_(computing)
http://www.pcworld.com/article/2158260/new-internet-explorer-zeroday-details-released-after-microsoft-fails-to-patch.html
>>53017339
Yep, 8 years gone unnoticed, and all systems were working normally
This bug could exist in Windows as we speak, but it's closed source so how would we know? I mean heck, even on a clean install the event log shows errors. I guess the world isn't all peaches and rainbow farts is it?
I love Windows and Linux, but please shut the fuck up and close the door on your way out of this thread and /g/
Sincerely,
Some random software engineer who's only human
Threadly reminder
>rendering your fonts in the kernel
>20XX
https://www.cvedetails.com/cve/CVE-2010-1255/
https://www.cvedetails.com/cve/CVE-2011-3402/
https://www.cvedetails.com/cve/CVE-2012-1867/
https://www.cvedetails.com/cve/CVE-2012-2897/
https://www.cvedetails.com/cve/CVE-2012-4786/
https://www.cvedetails.com/cve/CVE-2013-3129/
https://www.cvedetails.com/cve/CVE-2013-3894/
https://www.cvedetails.com/cve/CVE-2014-4148/
https://www.cvedetails.com/cve/CVE-2015-0059/
>>53017482
MICROSHAFT WANGBLOWS INDIAN INTERNET FORCE BLOWN THE FUCK OUT.
>THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
>>53016795
Because it has nothing to do with Linux. It's part of the GNU core utils.
>>53014954
> Every fucking day.
> Every single fucking day when i come home this little faggot just sits there and gives me this stupid look on his face.
> What should i do about him?
> Ideas?
can we finally agree that C's handling of arrays is an unmitigated disaster?
with quality GNU code how could this happen i wonder
the same kind of quality that's available in GNU's true.c, which is 64 lines long
>>53016917
I'm an newbie to Ubuntu, help? How do I use this?
>>53017653
>I'm an newbie
Chances are you are not vulnerable in the first place.
Also, update your shit. Debian team fixed this already
>>53017670
I updated but I'm seriously new to all of this.
Currently using Ubuntu Gnome 15
>>53017688
You're fine.
>>53017732
How do I know the updates worked,
all I did was sudo apt-get update and sudo apt-get upgrade
>>53017620
>can we finally agree that C's handling of arrays is an unmitigated disaster?
No. C is built for performance. Any other way of handling arrays that I know of is considerably slower. If you want safety at the cost of performance, don't use C.
Bounds checking is nice. I would agree that a general-purpose language should have it as an option (even for systems-level programming). But there are times when you don't want it.
>>53017761
>A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interest of efficiency on production runs. Unanimously, they urged us not to—they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.
>>53017761
you and every other retard on /g/ thinks array safety means doing dynamic bounds checks on every random access, and nothing less.
the getaddrinfo() bug, like Heartbleed and who knows what else, was just a simple buffer copy overflow.
the code was presumably already doing one, just incorrectly, which is easy to do as safe buffer copies in C are a Design Pattern relying on ad-hoc function parameters rather than something the language grammar and syntax facilitates in any way.
>>53017752
Normally by going through security mailing lists.
The security updates get the highest priority. Whenever any team finds a fix, it's shared with various other teams. Such as if RHEL finds a fix, debian, Arch, or other team will review the patch and push them into their updates. This is how open source community works
>>53017761
> bounds checking a linear (i.e., loop based) buffer copy is an extravagance
holy fuck how retarded is neo-/g/.
>>53017830 (You)
>checks on every random access
yeah, this is the expensive one, where there's merits to either choice.
there's no fucking excuse for a buffer copy.
>>53017289
There's probably tons of vulnerabilities in any OS that nobody knows about right now
D arrays >>>>>>>>>>>>> C arrays
>stores enough information to implement runtime bounds-checking
>incorporates unit testing into the language in a convenient way
>for debug builds, unit test the everloving fuck out of array handling code to catch and fix every conceivable OOB
>for release builds, where performance is absolutely critical, switch runtime bounds-checking off with a compiler flag
fite me
>>53018107
that sounds like mostly the right approach, but how does it handle selective bounds check disabling?
in a given program, there generally won't be too many random access hot points, and just testing them the most thoroughly and disabling their checks would seem more preferable than nuking all checks at the build level.
>>53018260
>selective bounds check disabling
I'm reasonably sure that it won't run bounds checking on simple loops likeint[] array = [0, 3, 7, 2, 9, 4];
for (int i = 0; i < array.length; i++)
{
array[i]......
}
but I'm not 100% about that
I know it doesn't bounds check if you use a foreach loop thoughforeach (int iter; array)
{
// iter is passed by value into here, i.e. a copy
}
or if you want to access elements by reference - to change them or if a copy is going to kill performanceforeach (ref int iter; array)
{
iter++
}
assert(array == [1, 4, 8, 3, 10, 5]);
which should allow you to explicitly eliminate 90% of superfluous bounds-checking
>already patched
>>53017124
You also don't need Linux to run GNU.
>>53018429
if those cases aren't ALWAYS optimized out, Walter Bright needs to be shot.
the only thing that benefits from extra runtime bounds checking is true random access: when an array index is passed from an outside source.
>>53018429
>which should allow you to explicitly eliminate 90% of superfluous bounds-checking
In combination with array slicing, I mean
so to iterate through only the 2nd to 5th element of an array you can doforeach (int elem; array[1..5])
(it's inclusive at the bottom and exclusive at the top - zero indexed obviously)
and to only do the last two in an arrayforeach (int elem; array[$ - 2..$])
($ in an array subscript will be replaced with array.length)
and of course, slices don't copy the elements, they just copy the array structure, i.e. a pointer to the first element and a pointer to the last
You can turn bounds checking off with a compiler flag, but most of the time you won't need to because a lot of meaningful D can be written that wouldn't use bounds checking even if it was available
>>53018555
well I know foreach loops don't bounds check
I only say I assume the first one doesn't because I don't know for sure, but Walter Bright is a clever guy, so I'm like 99% certain
