Slashdot Mirror

Comin' at ya

True, and contrary to quite a few other posts here, there is a lot of activity and updating/modernization going on. For example: Debian Continuous Integration which is only a few years old.

I think the disgruntled maintainer should consider running for the Debian Project Leader position which is open right now and advocate for changes he wants.

Ruby is faster than Python by many metrics. It doesn't really matter: execution speed isn't the bottle-neck for the vast majority of websites.

Firefox in Rust today is doing a lot better than Chrome in C++ today, especially with regards to memory consumption.

There should not be any significant differences in memory consumption between Rust and C++, as per design since the compilers emit similar instructions.

https://benchmarksgame-team.pa...

I don't understand the need for some to wave away all the problems with them. I would much prefer that the compiler tells me about array overflows etc, or at least give me a way to write a type that gives me automatic checking of bounds.

It's called code static checking, but unfortunately it cannot be done at compile time for more complicated algorithms, especially with external parameters. At least partially, it can be done dynamically for debug/profile binaries, but all the checks are removed from the actual released product, and the undiscovered errors can be cumbersome to debug in the future. Also in *most* cases the runtime checked and C/C++ binaries have similar performance, primarily because even the safe languages aggressively optimize the code by eliminating redundant checks (for example, array iteration, it's not necessary to perform bound checks for every index/iterator access, it can be done once before the iteration) and also because in C/C++ the majority of such runtime checks are still performed manually or are done in standard template libraries. Just look at Rust vs C++ benchmarks, in some cases Rust generated faster code and it could be optimized even further. Also for performance critical parts (where the compiler can't eliminate the unneeded checks, or you are writing a driver) Rust lets you write unsafe blocks where no dynamic checks are performed and you can also work with raw pointers, pretty much like in C/C++. There is even an OS kernel written in Rust. The fundamental difference is that Rust is safe by default, and only in few performance critical parts you need to tell the compiler that you know 100% what you are doing. C++ is mostly C by default and C is unsafe by default.

If you don't care about performance then choose Java or C#, it's can get to up to 60% to 80% performance of C++ and you don't need to worry about all the pitfalls

Go here if you want to see how 'slow' C++ is:

https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/cpp.html

He said it because he's an idiot Python programmer. The type of which I mentioned in one of my bullet points as being someone I'd rather not be associated with by also jumping in the Python cesspool. I like your analogy. However, it's not dramatic enough. I am aware that some tractors can go as fast as 87 MPH. Given that an F1 car is about 230 MPH, that's less than three times faster. More closely mirroring real actual comparisons it would be closer to a Peregrine falcon (240MPH in a dive) being compared to a sea turtle (4-6 MPH) or about (about 1/50th or so, at best) . The ratio in the Mandelbrot benchmark was actually 170x faster which is even worse.

It's a trend though. There is a certain type of youngster that thinks anything "old" sucks. C and Unix count as "old" so they want to poison (systemd) and/or replace them (merge Linux into Windows subsystems) because they don't fit their world view that scripting languages are fast enough for everybody and everything and C & Unix is too hard because "it's old" not because they are simply too lazy or simpleminded to learn them. These ignorant children have got themselves so wrapped around this self-deception that they actually go out into the world and say shit like "Python is comparable to C". Homeboy will probably never come back and read or argue about it because that might disabuse him of his ridiculous ideas.

You can create your own consistency. Do things consistently. If you can't go download 'astyle' and let it format you code more consistently. Why do you need some diktat to do that? Plus, if the only way to get that consistency is to screw the visually impaired (me) then the your cure is worse than the disease. Also you are completely and utterly full of dogshit about it being comparable to C speed. Not only does Python3 gets slapped around like a bitch by PHP (2-3 times slower in most cases than PHP? the shame!) but if you compare it to C then it just get's fully blown completely the fuck out of the water with almost all the results being HUNDREDS or at least dozens of times slower than C. Guess that's why you didn't provide any references to back that little tidbit up. Lastly, I never said that Python coders were friends. I'm mainly implying most of them are clueless children. You seem to fit that mold quite well and prove the point. Hehe, comparable to C.... I'm still trying to catch my breath from that one. Yeah, it's comparable, if you have a BIG fucking coefficient to multiply times before the comparison.

1. Uses idiotic control structures based on white space which greatly impedes vision impaired folks from using it. Plus, screw telling me how to format my code. That's a style issue.

2. Python3 performance is mostly inferior. Look how it performs even versus PHP (which Python coders seem to feel superior to - but they both suck).

3. Python leadership seems more concerned with SJW issues than coding. That's the perception when folks see shit like this.

4. The "feature" to mix spaces and tabs causes hella confusion around whether one white space or one tab is a bigger indent.

5. Coding in Python often requires hanging out with Python coders who are often myopic, technically underweight, and generally inexperienced and annoying.

Save yourself some heartache, don't worry about the SJW issues in Python, and pick a superior language. There is a long list to choose from.

It really is and you blathering about what you don't know does not change that fact. (Python 14 minutes vs C++ 8..24 seconds for N-Body simulation.)

I've just run it on my machine. C++: 2.3 seconds, Python: 22 seconds. That's for straightforward mathy Python against C++ code with vector instrinsics. Concerning C++ code without manual vectorization, it's 4 seconds against 22. Not terribly bad, I'd say. Not to mention that this isn't the kind of code that would be typical for a larger application.

It really isn't.

It really is and you blathering about what you don't know does not change that fact. (Python 14 minutes vs C++ 8..24 seconds for N-Body simulation.)

I pointed out that the answer was an evasion. I believe it is apparent that the real answer to my question is "no". Is there shame in that simple answer, and if so, why? Nothing stops anybody from following up with "no, but..." However, evasion... just don't do it. The message you send is "the true answer to the question would be harmful to my argument".

In this case, "no I have never used it" could be followed up with "however I have researched the question a lot, and I have these other data points I can also offer..." But that didn't happen. So now I am left with the impression that the anti-Rust argument was just rhetoric, based on nothing more than personal prejudice.

For the record, I have not written anything in Rust, however I have researched it a fair amount, I have installed it, and I do intend to try some toy programs in it. So far I mostly like what I see, especially the rather impressive performance.

I understand that some significant parts of Firefox have been re-implemented in Rust from the original C++. And I notice that Firefox has improved a lot in recent months, particularly in terms not leaking like it used to.

There is no "-1, disagree" moderation option.

I pointed out that the answer was an evasion. I believe it is apparent that the real answer to my question is "no". Is there shame in that simple answer, and if so, why? Nothing stops anybody from following up with "no, but..." However, evasion... just don't do it. The message you send is "the true answer to the question would be harmful to my argument".

In this case, "no I have never used it" could be followed up with "however I have researched the question a lot, and I have these other data points I can also offer..." But that didn't happen. So now I am left with the impression that the anti-Rust argument was just rhetoric, based on nothing more than personal prejudice.

For the record, I have not written anything in Rust, however I have researched it a fair amount, I have installed it, and I do intend to try some toy programs in it. So far I mostly like what I see, especially the rather impressive performance.

I understand that some significant parts of Firefox have been re-implemented in Rust from the original C++. And I notice that Firefox has improved a lot in recent months, particularly in terms not leaking like it used to.

There's a really obnoxious regression in the Nouveau module that causes a kernel panic on boot for people who have a GTX 660 (me being one of those people). This is the case on both a bare install and the live CD. It's apparently known and acknowledged but it hasn't been fixed in the stock kernel for 9.1 (kernel version 4.9). The 3.16 kernel in Debian 8 still works fine. I'll keep testing it as they make point releases I guess.

When I was hired at my current employer in 2012, I got a Thinkpad T-series laptop. I installed Debian Squeeze with the XFCE desktop environment on it, and it worked beautifully. I dist-upgraded that installation to Wheezy when that release was made. No problems, everything just continued working. After Wheezy became oldstable, I dist-upgraded to Jessie. No problems, everything just continued working. A few months ago, I switched to a Skylake-powered desktop machine, simply by transferring all the data on the Thinkpad's SSD to my new rig's larger one. No problems, everything just continued working.

Today I got a notification from Firefox (I install new releases via Debian's mozilla repository, https://mozilla.debian.net/) that it won't be able to play back sound if I didn't install PulseAudio. A quick `sudo apt-get install pulseaudio` and a reboot (to also apply a pending Kernel upgrade) later: No problems, everything just continued working. `mpv` defaults to the pulse output instead of alsa automatically, apparently. Firefox, once again, plays back sound out of the box. My desktop audio player (some xmms-fork whose name I can't recall right now) needed to be switched from plain ALSA to pulse via its configuration panel - that was it. My stereo headset becomes the active, default output once I plug it in, and the speakers assume that role as soon as I unplug it. Also, the PulseAudio/pavucontrol features I gained from finally switching are pretty neat.

Bottom line, I guess: PulseAudio in 2017 _just effin' works_. Save yourself some time, skip the whining and bitching, get with the times and install it already.

I thought Microsoft got rid of program manager 20 years ago.

It sounds like Microsoft is going to use Delta Updates which is kind of strange since Microsoft were one of the first companies to actually use this methodology in Windows XP. Forcing a 4GB update (as per article) is just plain lazy.

I have been using Fedora (stable version) for years and from 2009 most updates come in the form of "deltas" such that over a month I would probably download less than 1GB and anyone who has used Fedora would know that updates are very common on that Linux distribution, which for me is less than 9GB in overall size and includes 2,200 packages. Unfortunately, some packages don't support deltas and Google Chrome (approx 40MB to 80MB) I am looking at you.

Note: Even though I do get allot of updates I rarely have conflicts and if I do I can just lock out the offending package or just don't update until the issue is fixed which on average is one or two days.

BTW. Debian supports optional debdelta but Ubuntu dropped this in 2011.

One nice thing with updates on most Linux distribution is the fact they can be automatic (you control the times) or if manual can be controlled by GUI or command line. In all cases, updates don't impact what you are doing unless you really do have a very old computer then you should not update until after you have finished what you are doing. No matter what method you choose you are totally in control.

Microsoft is calling delta updates "Unified Update Platform (UUP)" which I suppose for them is more "hip". Still, unless you write software that can support deltas and this applies to all packages and operating systems then the methodology is useless.

Even with bad passwords, it's much harder for attackers to gain access to accounts, and the number of accounts compromised should be reduced.

Please review the following quick demo. It took me less than an hour to produce, including the run time to generate its output using a single CPU core of an old Celeron G540 box (vintage 2011 desktop hardware). You should notice that it generates pseudo-random crappy 8 character lowercase passwords (which still beats what a lot of folks use) and produces salted SHA-256 hashes of them. For the first run, a static salt of "yahoo.com" is used for each salted hash. For the second run, nine randomly selected bytes from the standard ASCII set are used for each salted hash. The end result is 225 people unwittingly sharing the same hash in the first case, and zero duplicate hashes for the second case.

Demo: rand-salt.pl

Please let me know when I may collect my $1,000. My family sure could use the money; I've got kids. That said, I'm also committing to send 25% of the funds ($250) to gweihir as an expression of my appreciation for his contributions to the Slashdot community over the years. You have my word on that. Let's see if you keep your word in turn. Your move.

The parent is probably referring to the fact that CDDL is NOT compatible with the GPL.

https://lists.debian.org/debia...

Unfortunately Sun then developed the CDDL[1] and JÃrg Schilling
released parts of recent versions of cdrtools under this license.
The CDDL is incompatible with the GPL. The FSF itself says that this
is the case as do people who helped draft the CDDL. One current and
one former Sun employee visited the annual Debian conference in Mexico
in 2006. Danese Cooper clearly stated there that the CDDL was
intentionally modelled on the MPL in order to make it GPL-
incompatible. For everyone who wants to hear this first-hand, we have
video from that talk available at [2].

You can read the FSF position about the CDDL at [3]. The thread behind
[4] contains statements on the issue made by Debian people; for more
context also see the other mails in that thread.
In short - the CDDL has extra restrictions, which the GPL does not
allow. JÃrg has a different opinion about this and has repeatedly
stated that the CDDL is not incompatible, interpreting a facial
expression in the above-mentioned video, calling us liars and generally
appearing unwilling to consider our concerns (he never replied to the
parts where we explained why it is incompatible). As he has basically
ignored what we have said, we have no choice but to fork. While the CDDL
*may* be a free license, we never questioned if it is free or not, as it
is not our place to decide this as the Debian cdrtools
maintainers. However, having been approved by OSI doesn't mean it's ok
for any usage, as JÃrg unfortunately seems to assume. There are several
OSI-approved licenses that are GPL-incompatible and CDDL is one of
them. That is and always was our point.

[1] http://www.opensource.org/lice...
[2] http://meetings-archive.debian...
[3] http://www.gnu.org/licenses/li...
[4] http://lists.debian.org/debian...

I strongly suggest watching Vincent Sanders and Daniel Silverstone at their 2007 DebConf talk, From concept to concrete. It's far from my work line, but I clearly remember it as informative and fun — eight years later!

For all practical purposes, CLANG is useless if you want to develop C++.

Are you high?

CLANG is incompatible with libstdc++

Are you high?

or microsoft's c++ library.

Are you high?

Which means you have to use the libc++ that they supply.

Are you high?

Unfortunately libc++ is not available on windows, so any app that uses C++ features is out.

Finally a vaguely true-ish statement. Nobody's maintained libc++ on Windows in years. Of course, you could just use clang with MSVC's C++ STL or the libstdc++ one, or Dinkumware, or ...

On linux, if you want to use the C++ features, it is pretty much impossible to cross-link against libc++ and the other libs on your distribution that may be complied with g++, so you have to compile every library you want with with CLANG to use and ship a static binary (or ship the libs and have your startup script setup library paths etc).

Clang and GCC are ABI compatible and always have been barring bugs (yes, GCC also has ABI bugs). You can link libraries built with either compiler, even picking individual .o files.

Of course, many of the common open source C++ libs do not compile with CLANG anyway so you are screwed.

Yes, GCC accepts invalid code, programmers write invalid code.

These days, most programs have fixed their code and build with clang just fine. For instance only 5.9% of Debian packages failed to build with clang.

In summary, unless you are writing console only apps and do not need to link to any c++ library other than libc++, CLANG is not even an option for you.

For example, Chrome build with clang on Linux, Mac and Windows, using libstdc++ on Linux, libc++ on Mac and the MSVC C++ libary on Windows. The Mac and LInux versions built with clang are what Google actually ships.

iceweasel is an older firefox and ESR release, currently both is an advantage

Actually Iceweasel is available in the same versioning as Firefox - the difference is that the Debian packagers backport security patches to older versions. i.e. I'm running v39.0 (39.0-1~bpo70+1 on Wheezy as I type)

If I chose the default version that comes with oldoldstable (squeeze) I'd be running 3.5.16-20.

Every release from oldoldstable to testing can make use of various releases. All releases except the latest get security patches backported - so if you don't like new features you can keep the older version without sacrificing security. (Thanks Monsieur Hommey and others)

if you are searching for code (eg function names and how to use them), then use a code search engine. Since google shut down theirs you can try https://code.openhub.net/ https://codesearch.debian.net/ ( !co and !dsource respectively on duckduckgo https://duckduckgo.com/bang )

1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.

2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.

3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.

4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.

5) You can laugh as you want, this will not change the reality:
* Sysadmins are a minority of Linux users.
* Distributions like Debian support /etc/network/interfaces with systemd.
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.

1) What's wrong calling a helper script a script that help you to do something in a more simple way? Now if it's not from you the script came from something else. In the context of this discussion this is from the distribution.

2) It's not the central part of system V init. The most obvious prof of this is that each distribution family have a different set of helpers scripts. Just take a look at the reality:
https://packages.debian.org/je...
https://packages.debian.org/je...
https://packages.debian.org/je...
If you list the source patch archive http://http.debian.net/debian/... you will see that ALL the initscripts are Debian specific and not part of the original sysvinit http://http.debian.net/debian/... .
Configuring the network is not the same in Fedora an in Debian. On of the long term goal of systemd is to normalize the situation.

3) The problem is to configure an interface automatically when the system boot. In most distribution the users don't even have to use the real command to setup the interface to do this. And you are completely wrong about your ifconfig and script theory: the vast majority of network interfaces are today setup by a dhcp client, or an application like NetworkManager according to DBUS messages coming for example from a GUI application, all written in C or C++, or maybe something other, but for certain shell scripts play a marginal role here. The shell is NOT the primary interface for the vast majority of the users, sysadmin is not the dominant specie in the Linux world.

4) Systemd is really simpler to learn that shell script. I switched some months ago to systemd and found all the documentation is needed in the usual man pages. I took me less than 1 hour to learn the basic commands and I was able to convert the custom part of the system less than one day.

5) You can laugh as you want, this will not change the reality:
* Sysadmins are a minority of Linux users.
* Distributions like Debian support /etc/network/interfaces with systemd.
* There are sysadmin already using systemd.
* To date there is no enough maintainers against systemd to have successfully make an serious alternative available and ready to use by the distribution.
* Systemd transition is now done by Fedora, Ubuntu and Debian and there are still there.
* Still, a lot of forum get post from 'sysadmin' complaining.

I just encountered a link about refracta. It turns out to be absurdly easy to fork Debian, at least for now.

Refracta is rather close to Debian testing. Its home page
is http://www.ibiblio.org/refract...

At http://forums.debian.net/viewt... it is described as
(for testing, without libsystemd0, it's pinned).

It even uses the Debian repositories!

Are there any other forks?

-- hendrik

I don't think you're being argumentative at all. Your points are fair and valid, and I'll note that the specific example provided (per the comments embedded in it) is a bit on the contrived side. That said, Perl actually used to just use whatever it found in $ENV{SHELL} for system() calls, which would have removed the necessity of including the explicit /bin/bash call to trigger the bad behavior, but that behavior was fixed some time ago. Other programming languages and environments may be quite a bit more lax, shifting more of the security burden onto the general operating system environment and further abstracting unsafe lower-level calls away from the programmer.

However, the earlier example is still quite useful for demonstrating another Perl best practice: taint mode. I have seen some truly dreadful things done via shell-outs in various languages, because programmers are of course capable of doing all sorts of very silly and dangerous things in their programs (such as including direct shell binary invocations in system calls), frequently without realizing those things are that dangerous in context. This may be due to the dangers being difficult to anticipate, and this could be said of our first example, as it doesn't contain any code that visibly uses external data. Here's what happens when we turn on taint mode in the initially exploitable script: Perl taint mode saves lives.

If I get the time, I'll be setting up various test environments with an assortment of examples written in different languages and frameworks to demonstrate the sorts of differences described herein, and I'll be glad to keep you posted if you like.

I put together a small example for you.

How many machines are out there that don't have a DVD drive? OK, I have one, gathering dust. I'll modify the question: how many machines are in use that have a CD drive but not a DVD one?

The last time I used Live Build, it produces (by default) an image that will work on USB or optical media.
http://live.debian.net/manual/...

If size is the problem, you can customize what packages are installed till you get below 700M.

No really sure what you're whining about, to be honest.

My laptop is three years old and doesn't have an optical drive at all.

How many machines are out there that don't have a DVD drive? OK, I have one, gathering dust. I'll modify the question: how many machines are in use that have a CD drive but not a DVD one?

The last time I used Live Build, it produces (by default) an image that will work on USB or optical media.
http://live.debian.net/manual/...

If size is the problem, you can customize what packages are installed till you get below 700M.

No really sure what you're whining about, to be honest.

There is already a project to build Debian with LLVM/Clang.

http://clang.debian.net/

In reply to the question posed in your subject line, I suggest simply prepending "\" characters to each line of your beta. This should be sufficient to escape it in most shells. HTH, HAND.

Yeah, I knew about that possibility before, but since the data to be stored on Mozilla servers was being properly encrypted on my device and in my client, I opted out of the usual "maintain my own infrastructure" chores that one time. Now, the "old" (read: current) Firefox Sync system is going away completely in the not too distant future, and you'll probably have to install some kind of add-on to keep your existing, self-hosted infrastructure functional. Meanwhile, I asked some Mozilla people/developers what the change was about, and how the new system is supposed to keep users' data confidential. The transcript of the IRC session is available here, on Debian's inofficial pastebin - enjoy! :)

Lets be honest this is more about Mir and Unity(and maybe Amazon integration for a few of us), being promoted over *Alternatives* and both have been discussed on and off topic to death. Whatever you personally think of these choices, users currently have a choice of Desktop(and I am still not going to choose Unity), and Mir is still a twinkle Shuttleworth's eye. I am personally using the very polished Xubuntu(promoted by the Cinnamon split from Gmone), which smooths over the clash between GTK2/3, and other than a stupid oversight with the volume indicator. Has been the best desktop I have ever used...and yes I do miss a few Gnome features, but it has its own to love, and I am in love with Gmusicbrowser.

The bottom line it is still is the no brainer Linux install...unless you are wedded to (the still wonderful) Cinnamon (personally I am keeping my eye on Cut http://cut.debian.net/ ), I wish Canonical all the luck with their phone, If they can wed themselves to decent Chinese manufacturer that can produce low cost phones. It may be my next phone.

That has nothing to do with the server at screen.palegray.net, which is a Debian VM running nginx to serve screen capture images. You're probably using Internet Explorer, and you're probably being prompted for whether or not you want to download the image file. The only thing being served from that link is in fact a PNG image (transcript from a simple curl test in a terminal on a Mac).

Calling someone an arsehole is pretty dumb when the "problem" at hand isn't even a problem, and instead arises from ignorance on your part.

While we're on the subject of the Debian website (all emphasis added):

Q: How is security handled for testing?

A: If you want to have a secure (and stable) server you are strongly encouraged to stay with stable. However, there is security support for testing: The Debian testing security team handles issues for testing. They will make sure that the fixed packages enter testing in the usual way by migration from unstable (with reduced quarantine time), or, if that still takes too long, make them available via the normal http://security.debian.org/ infrastructure. To use it, make sure the following line is in /etc/apt/sources.list:

deb http://security.debian.org/ /updates main

and run apt-get update && apt-get upgrade as usual.

Note that this doesn't guarantee that all known security bugs are fixed in testing! Some updated packages might be waiting for transition to testing. More information about the security infrastructure for testing can be found at http://secure-testing-master.debian.net/.

Well I don't know about you but I'm convinced? What Debian realistically needs to do is take what they call "testing" and call it "stable" if they ever want to catch up. Most people who are trying Debian now are trying it because of the constant stream of bad news from Canonical (Mir, Dash Lens and it's reassurance that your searches won't ever be linked to you, thus making them worthless...and of course Unity). Shortly after they realize that the latest NVidia driver available from official repositories is 304.88 and the best of an interface they get is either GNOME 3 four point releases behind mainstream, or KDE 4 at least 2 point releases behind mainstream...and then they start wondering why they installed fucking Debian.

No, it's not. http://secure-testing-master.debian.net/

Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

You asked for it, Debian delivers. The Debian CUT Project aims to publish usable snapshots of Debian Testing on a monthly basis. They're pretty new but picking up steam.

Don't forget Linux Mint Debian (the version based on Debian instead of Ubuntu, just as the name implies), my understanding is that they take big portions of test and deliver them in chunks, so you have a slightly more stable update cycle but still get the frequent updates.

Except Ubuntu users want cutting edge Debian, not tried and tested Debian...and unfortunately using Debian is not going to make it more cutting edge.

...Now if Debian decided to produce a (stable) cutting edge Desktop version (perhaps working with an existing Distribution team). To complete there ultra stable, you have me sold.

You asked for it, Debian delivers. The Debian CUT Project aims to publish usable snapshots of Debian Testing on a monthly basis. They're pretty new but picking up steam.

Nigger, please. I actually did look at the source code. There's a single call to fillStyle and fillRect each. The same can be done and was done in 1980's home computer BASIC.

unminified: http://paste.debian.net/245039/

Same here. Debian Sid is great when Testing isn't frozen, but then it stops being fun for far too long. If I wanted to run Stable, I'd run Stable, and if I want to run a rolling distro, I'd rather not run some slow-moving, semi-stable slush.

Seconded. I've heard aptosid improves things slightly, but a lot of the packages I'm interested in aren't there (e.g. KDE). I've considered setting up a VM to automatically source packages from the Ubuntu repos and recompile them for Debian - not sure how well that would work. (If there's an existing repo that does this, please let me know.) Even a list of repos like this one would be quite useful.

Well, have a better look before spreading lies. For kernel, web browser and libreoffice

Kernel:
Stable - 2.6
Testing - 3.2
Unstable - 3.2 (released July, 2012)
Current version - 3.8
Those 3.6/3.7 files seen in your link? Experimental. Yeah you could make it work, but then you aren't running Sid anymore. Not entirely. And if you run too much experimental for too long, something is going to end up horribly broken.

Firefox/Iceweasel:
Stable - 3.5
Testing - 10esr
Unstable - 10esr (released March 2012)
Current Version - 19.0

Libreoffice:
Stable - 3.5
Testing - 3.5
Unstable - 3.5 (released February 2012)
Current version - 4.0

YOU DO have very recent packages available, even right now, during the freeze of testing. I haven't checked DE and X, since I don't know what you run (eg: which graphic card, and which environment you like).

I run XFCE on testing, not that it matters.

XFCE:
Stable - 4.6
Testing - 4.8
Unstable - 4.8 (released Jan 2011)
Current Version - 4.10 (released April 2012)

Like I said, Sid isn't bleeding edge. Of the packages here, the newest in Sid is the kernel: 7 months old.

It's also worth noting that drivers receive unblock from the release team so that they can enter stable.

Well that's great (and I genuinely mean that), but a bleeding-edge enthusiast would only see that 3.2 != 3.8.

Well, have a better look before spreading lies. For kernel, web browser and libreoffice, YOU DO have very recent packages available, even right now, during the freeze of testing. I haven't checked DE and X, since I don't know what you run (eg: which graphic card, and which environment you like). But I know that the latest Nouveau driver went in for Wheezy. It's also worth noting that drivers receive unblock from the release team so that they can enter stable.

Please stop repeating the bul**hit that everyone tells without taking the time to check.

50 Million Potentially Vulnerable to UPnP Flaws - January 2013 Articles and Downloads

###

Multi-Article Document:

Part 1 - Article: 50 Million Potentially Vulnerable to UPnP Flaws
Part 2 - Article: Security Flaws in Universal Plug and Play: Unplug, Don't Play
Part 3 - Router Scan: Universal Plug and Play - Router Security Check
Part 4 - Download: ScanNow for Universal Plug and Play (UPnP) | For Windows
Part 5 - PDF: Whitepaper: Security Flaws in Universal Plug and Play: Unplug, Don't Play.
Part 6 - Article: Millions of devices vulnerable via UPnP
Part 7 - Article and Discussion: 50 Million Potentially Vulnerable To UPnP Flaws

###

Translate this collection (does not include software download(s) and PDF(s): http://translate.google.com/

###

COPYRIGHT: The New Zealand Copyright Act 1994 specifies certain circumstances where all or a substantial part of a copyright work may be used
without the copyright owner's permission. A "fair dealing" with copyright material does not infringe copyright if it is for the following
purposes: research or private study; criticism or review; or reporting current events.

###

This Multi-Article Document Has Been Mirrored At The Following Sites (RAW = text):

http://hpaste.org/81561 (RAW: http://hpaste.org/raw/81561)
http://kpaste.net/66c9a3
http://oxynux.org/pastebin/n3rae9-1874
http://pastebin.com/XHkXHfuF (RAW: http://pastebin.com/raw.php?i=XHkXHfuF)
http://paste.blixt.org/9819498
http://paste.lisp.org/display/135035 (RAW: http://paste.lisp.org/display/135035/raw)
http://paste.yt/p2605.html (RAW: http://paste.yt/P2605.txt)
http://slexy.org/view/s2r3Si2W3C
https://paste.debian.net/230670/
http://www.inetpro.org/pastebin/11699 (RAW: http://www.inetpro.org/pastebin/11699/view/raw)

###

(Part 1): 50 Million Potentially Vulnerable to UPnP Flaws

by Brian Donohue | January 29, 2013, 1:15PM

https://threatpost.com/en_us/blogs/50-million-potentially-vulnerable-upnp-flaws-012913

"In a project that found more than 80 million unique IP addresses responding to Universal Plug and Play (UPnP) discovery requests, researchers at Rapid7 were shocked to find that somewhere between 40 and 50 million of those are vulnerable to at least one of three known attacks.

A Rapid7 white paper enumerated UPnP-exposed systems connected to the Internet and identified the number of vulnerabilities present in common configurations. Researchers found that more than 6,900 product models produced by 1,500 different vendors contained at least one known vulnerability, with 23 million systems housing the same remote code execution flaw.

Between June 1 and Nov. 17, 2012, Rapid7 conducted weekly scans that sent simple service discovery protocUPnPol (SSDP) requests to each routable IPv4 address. In all, 2.2 percent of all public IPv4 addresses responded to the standard UPnP discovery requests. So, 81 million unique IP addresses responded and, upon deeper probing, researchers determined some 17 million further systems exposed the UPnP simple object access protocol (SOAP). This level of exposure was far higher than researchers had expected, according to

Archived @:
http://slexy.org/view/s21UWKzafS
http://hpaste.org/79175
https://paste.debian.net/plain/216145
======
The hum that helps to fight crime (ENF) Electrical Network Frequency analysis

"For the last seven years, at the Metropolitan Police forensic lab in south London, audio specialists have been continuously recording the sound of mains electricity.

It is an all pervasive hum that we normally cannot hear. But boost it a little, and a metallic and not very pleasant buzz fills the air. ...

"The power is sent out over the national grid to factories, shops and of course our homes. Normally this frequency, known as the mains frequency, is about 50Hz," explains Dr Alan Cooper, a senior digital forensic practitioner at the Met Police.

Any digital recording made anywhere near an electrical power source, be it plug socket, light or pylon, will pick up this noise and it will be embedded throughout the audio.

This buzz is an annoyance for sound engineers trying to make the highest quality recordings. But for forensic experts, it has turned out to be an invaluable tool in the fight against crime.

While the frequency of the electricity supplied by the national grid is about 50Hz, if you look at it over time, you can see minute fluctuations. ...

Comparing the unique pattern of the frequencies on an audio recording with a database that has been logging these changes for 24 hours a day, 365 days a year provides a digital watermark: a date and time stamp on the recording.

Philip Harrison, from JP French Associates, another forensic audio laboratory that has been logging the hum for several years, says: "Even if [the hum] is picked up at a very low level that you cannot hear, we can extract this information."

It is a technique known as Electric Network Frequency (ENF) analysis, and it is helping forensic scientists to separate genuine, unedited recordings from those that have been tampered with."

- http://www.bbc.co.uk/news/science-environment-20629671
- http://cryptogon.com/?p=32789

#

Met lab claims 'biggest breakthrough since Watergate'
Power lines act as police informers

- http://www.theregister.co.uk/2010/06/01/enf_met_police/

#

Noisy, muffled, incoherent recordings are an audio engineerâ(TM)s worst nightmare, but all too often they contain vital evidence in criminal trials. Itâ(TM)s the job of the forensic audio specialist to extract that evidence.

- http://www.soundonsound.com/sos/jan10/articles/forensics.htm

#

(discussion forum) Electrical network frequency analysis, Mains frequency variations detectable in digital audio recordings?

- http://www.hydrogenaudio.org/forums/index.php?showtopic=81346

#

Met Police use electrical 'hum' to solve crimes

The Metropolitan Police is using the "hum" of background noise produced by mains electricity to help solve crimes, it has been disclosed.

- http://www.telegraph.co.uk/news/uknews/crime/9739037/Met-Police-use-electrical-hum-to-solve-crimes.html

#

Related Research
- http://www.ece.umd.edu/~ravig/Research.html

#

Engineers Use Electrical Hum To Fight Crime

- http://science.slashdot.org/story/12/12/12/1331243/engine

Archived @:
http://slexy.org/view/s2w3SOkgpA
http://hpaste.org/79169
https://paste.debian.net/plain/216147
===
CIA Head: We Will Spy On Americans Through Electrical Appliances

Global information surveillance grid being constructed; willing Americans embrace gadgets used to spy on them

Steve Watson | Prisonplanet.com | March 16, 2012

http://www.prisonplanet.com/cia-head-we-will-spy-on-americans-through-electrical-appliances.html

"CIA director David Petraeus has said that the rise of new "smart" gadgets means that Americans are effectively bugging their own homes, saving US spy agencies a job when it identifies any "persons of interest".

Speaking at a summit for In-Q-Tel, the CIA's technology investment operation, Petraeus made the comments when discussing new technologies which aim to add processors and web connections to previously 'dumb' home appliances such as fridges, ovens and lighting systems.

Wired reports the details via its Danger Room Blog[1]:

"'Transformational' is an overused word, but I do believe it properly applies to these technologies," Petraeus enthused, "particularly to their effect on clandestine tradecraft."

"Items of interest will be located, identified, monitored, and remotely controlled through technologies such as radio-frequency identification, sensor networks, tiny embedded servers, and energy harvesters - all connected to the next-generation internet using abundant, low-cost, and high-power computing," Petraeus said.

"the latter now going to cloud computing, in many areas greater and greater supercomputing, and, ultimately, heading to quantum computing." the CIA head added.

Petraeus also stated that such devices within the home "change our notions of secrecy".

Petraeus' comments come in the same week that one of the biggest microchip companies in the world, ARM, unveiled new processors that are designed to give practically every household appliance an internet connection[2], in order that they can be remote controlled and operate in tandem with applications.

ARM describes the concept as an "internet of things".

Where will all the information from such devices be sent and analyzed? It can be no coincidence that the NSA is currently building a monolithic heavily fortified $2 billion facility[3] deep in the Utah desert and surrounded by mountains. The facility is set to go fully live in September 2013.

"The Utah data center is the centerpiece of the Global Information Grid, a military project that will handle yottabytes of data, an amount so huge that there is no other data unit after it." reports Gizmodo.

"This center-with every listening post, spy satellite and NSA datacenter connected to it, will make the NSA the most powerful spy agency in the world."

Wired reports[4] that the incoming data is being mined by plugging into telecommunications companies' switches, essentially the same method the NSA infamously uses for warrantless wiretapping of domestic communications[5], as exposed six years ago.

Former intelligence analyst turned best selling author James Bamford, has penned a lengthy piece[6] on the NSA facility and warns "It is, in some measure, the realization of the 'total information awareness' program created during the first term of the Bush administration-an effort that was killed by Congress in 2003 after it caused an outcry over its potential for invading Americans' privacy."

--

Steve Watson is the London based writer and editor for Alex Jones' Infowars.net[7], and Prisonplanet.com[8]. He has a Masters Degree in International Relations from the School of Politics at The University of Nottingham in England.

(C) 2012 PrisonPlanet.com is a Free Speech Systems, LLC company. All rights reserved.

[1]

Archived @:
http://slexy.org/view/s21UWKzafS
http://hpaste.org/79175
https://paste.debian.net/plain/216145
==
The hum that helps to fight crime (ENF) Electrical Network Frequency analysis

"For the last seven years, at the Metropolitan Police forensic lab in south London, audio specialists have been continuously recording the sound of mains electricity.

It is an all pervasive hum that we normally cannot hear. But boost it a little, and a metallic and not very pleasant buzz fills the air. ...

"The power is sent out over the national grid to factories, shops and of course our homes. Normally this frequency, known as the mains frequency, is about 50Hz," explains Dr Alan Cooper, a senior digital forensic practitioner at the Met Police.

Any digital recording made anywhere near an electrical power source, be it plug socket, light or pylon, will pick up this noise and it will be embedded throughout the audio.

This buzz is an annoyance for sound engineers trying to make the highest quality recordings. But for forensic experts, it has turned out to be an invaluable tool in the fight against crime.

While the frequency of the electricity supplied by the national grid is about 50Hz, if you look at it over time, you can see minute fluctuations. ...

Comparing the unique pattern of the frequencies on an audio recording with a database that has been logging these changes for 24 hours a day, 365 days a year provides a digital watermark: a date and time stamp on the recording.

Philip Harrison, from JP French Associates, another forensic audio laboratory that has been logging the hum for several years, says: "Even if [the hum] is picked up at a very low level that you cannot hear, we can extract this information."

It is a technique known as Electric Network Frequency (ENF) analysis, and it is helping forensic scientists to separate genuine, unedited recordings from those that have been tampered with."

- http://www.bbc.co.uk/news/science-environment-20629671
- http://cryptogon.com/?p=32789

#

Met lab claims 'biggest breakthrough since Watergate'
Power lines act as police informers

- http://www.theregister.co.uk/2010/06/01/enf_met_police/

#

Noisy, muffled, incoherent recordings are an audio engineerâ(TM)s worst nightmare, but all too often they contain vital evidence in criminal trials. Itâ(TM)s the job of the forensic audio specialist to extract that evidence.

- http://www.soundonsound.com/sos/jan10/articles/forensics.htm

#

(discussion forum) Electrical network frequency analysis, Mains frequency variations detectable in digital audio recordings?

- http://www.hydrogenaudio.org/forums/index.php?showtopic=81346

#

Met Police use electrical 'hum' to solve crimes

The Metropolitan Police is using the "hum" of background noise produced by mains electricity to help solve crimes, it has been disclosed.

- http://www.telegraph.co.uk/news/uknews/crime/9739037/Met-Police-use-electrical-hum-to-solve-crimes.html

#

Related Research
- http://www.ece.umd.edu/~ravig/Research.html

#

Engineers Use Electrical Hum To Fight Crime

- http://science.slashdot.org/story/12/12/12/1331243/engineers-

Linux is indeed used in many scientific fields. Speed? Customization? Open source tools? Probably all the above. If anyone is working on Neuroscience, for example, I bet he/she already knows NeuroDebian or will be interested to use it.

It raises the question... given the much better featureset, why are the major Linux distributions still using GCC to compile the kernel and all the OS packages?

LOL. As if those features matter very much to almost anyone. At this time, if you're developing C, it would be a really wise idea to verify code compiles under both and actually ship GCC compiled binaries because they're better (faster). Lack of optimization under clang is a bug, not a feature, unless you're doing human-powered-optimization like refactoring etc etc.

Its unlikely you'll "ever" be able to totally drop gcc... there are features that clang architecturally opposed to. Specifically fortran/C stuff, and the alternative GCC languages in general. Also its not a binary either/or. This is hardly the first time a OS has had to deal with an alternatives system. On debian, the alternatives system is called the alternatives system. I suppose other OS might have a different named system, and it might work somewhat differently, but the concepts will all be the same.

For a good time you can examine

http://clang.debian.net/

About 1 in 10 packages fail compilation. That percentage is steadily and constantly decreasing but it will never drop to zero obviously because at least some "OK on GCC" failure are due to two bugs correcting themselves, weird corner cases that the clang guys will never accept as a bugfix and the upstream will never tolerate, etc.

Now, compiles without error does not mean the binaries actually work. You'd need a full unit testing setup. Compiles but insta-segfaults is not success. Compiles but fails to output correct data is not success. Compiles but anything that uses it fails in some odd way (contemplate a library that compiles, but does not play well with others) So the actual failure rate is obviously somewhat in excess of 10%.

The next issue is thats 10% of Debian packages. Obviously installing clang and messing with the symlinks and compiling Eclipse (written in java) proves very little to nothing about the clang c and c++ compiler, because its not used for java. I would guess that only a large fraction of Debian packages use C or C++. So the actual failure rate for clang when rubbed up against "real world" source code is apparently far in excess of 10%.

Certain general application classes probably have higher or lower failure rates. The failure rate for C operating systems is probably not going to be similar to the failure rate for high performance numerical computing.

So the scales of justice weigh:

GCC: Positives: Free-er society/culture, much faster binaries, and it actually works. Negatives: fully/partially automatic refactoring and source analysis tool writers have a somewhat more difficult time

clang: Positives: People writing source analysis, refactoring type tools prefer working with clang. Negatives: BSD license encourages (at least permits) anti-social behavior, well over a tenth of your code will not compile without problems.

Hmm I think I'll be sticking with GCC for a good long time. Predictions about a decade in the future are pointless, could go either way. For ideological purposes I'd much prefer a GPL / GCC world, much healthier and free-er and more social.

The Debian Mozilla Team provides a very simple page describing how to use just about any current version of Firefox/Iceweasel on any current version of Debian.

I'm still using Squeeze myself and I've been getting the lastest verisons of Iceweasel within a day or so of them being released.

There is a Debian Live CD you can use.