Slashdot Mirror

You should encrypt it before sending it out to the service provider. This way you don't care, what method THEY are using. In fact, you'd rather they used none at all.

Personally, I am happy with CCrypt, which is a secure replacement for the simple-minded Unix crypt(1) utility. The FreeBSD port makes installing a breeze, as usual.

I've read about dtrace and wanted to try it for awhile, posts to BSDForums haven't helped me either. I don't have it in my ports tree, and it's not listed on Freshports: http://www.freshports.org/search.php?query=dtrace& search=go&num=10&stype=name&method=match&deleted=e xcludedeleted&start=1&casesensitivity=caseinsensit ive

Anyone know how to get ahold of a copy? I've created ports before so I'm not afraid to try some 'testing' version.

Thanks

You do need to "register" with Sun to get the source, but same goes even for New York Times... The registration is free.

You do need to "register" with Sun to get the source, but same goes even for New York Times... The registration is free.

You do need to "register" with Sun to get the source, but same goes even for New York Times... The registration is free.

Knowing a bit about what you're doing is fairly important with ports, especially when dealing with complex upgrades like Gnome; dependency tracking's a lot less anal than apt/dpkg. This is good when you've got something installed from outside ports, and works nicely when you just want to pick and choose a few things to update (say, after running portaudit or tracking an interesting update on FreshPorts/commit logs).

Geeky FreeBSD users need a desktop too, and now we have three variants to choose from; FreeBSD, PC BSD and DesktopBSD. YMMV; just because it's aimed at desktops doesn't mean it's aimed at yours or your mother's.

I use it as a desktop/workstation. Neverwinter Nights runs very well on it with Nvidia's driver.

Aren't the drivers for FreeBSD over a year old?

This and the lack of java is why I left FBSD behind.

It pisses me off.

Aren't the drivers for FreeBSD over a year old?

This and the lack of java is why I left FBSD behind.

It pisses me off.

Aren't the drivers for FreeBSD over a year old?

This and the lack of java is why I left FBSD behind.

It pisses me off.

That being said, it also could learn a bunch of things from other systems (though i don't hold my breath on this happening any time soon).

Particularly it could learn a few things from its famous progeny: portage.

I love the idea of portage whereby absolutely everything in Gentoo is a package (i'm typing this on my Gentoo powered laptop). However, I don't find it nearly as stable as my FreeBSD ports-based box. (This may be partly just the nature of Linux where bits and pieces of the core system get swapped and upgraded so much, and not entirely Gentoo).

Things that I'd love to see from portage (and other places) brought to FreeBSD:

1. ability to have more than one version of a port maintained at the same time.
2. ports system ported to a more manageable and extendable language than just shell scripts.
3. ability to have ports that maintain and build from SVN/CVS, or whatever, version control.
4. pkg-plists auto-generated by the install process (which helps make the last point manageable---and ports easier to maintain).
5. some extremely useful elements of the great (the only reason I have ruby installed on my box) portupgrade script (i won't bother to itemize which ones) brought into the base ports system (not to mention porteasy and a few other scripts that have popped up to ease some of the ports awkwardness).

Ah sigh. This is all off topic anyhow...

And Gentoo is beaten fast and hard by FreeBSD.

OpenOffice is targeted at people like my mother writing documents for their work.

Your mother will not be able to build from source anyway. She would have to use pre-built binaries -- in the form of RPMs or BSD packages. Such packaging (whichever it is) allows to automatically install dependencies. Done.

I'm talking about building from source.

Wasting a little bit of space or bandwidth is simply not a problem any more these days.

So, you'd rather they package their own Java too? I mean, if the license allowed them to?

But you clearly don't even have a clue, of how much waste I'm talking about. The OOo_1.1.4_source.tar.gz is 219743Kb. Extracting it make 712218Kb. Of that at least 77044Kb is redundant right of the bat (and I'm sure, I missed something besides apache_java berkeleydb bitstream_vera_fonts boost curl dmake expat freetype icu jpeg libxml2 moz nas neon np_sdk openssl python regexp sablot sane sax stlport unixODBC unzip zlib.

Now, of those 712218Kb extracted, 34472Kb are BMP (!), PDF, HTML, PNG, JPG, and dictionary files. Plus 20723Kb of pre-built JARs. Even assuming that everything else is source, the redundancy is already at over 30% (219743 out of 712218-34472-20723=657023). JARs and .tar.gz-s don't compress well either, which explain the poor compression ratio of their releases -- the redundant crap accounts for even more bandwidth waste than for storage waste (less valuable resource, BTW).

Now, there is source and there is source. OOo bundles STLPort -- and several versions of it. Do you realize, what kind of a beast that is? And not so much in size as in time it takes to build it and the effort it takes to port it to a new platform (OOo does not build on FreeBSD/amd64, for example, one has to port it manually). Other packages they ship similarly require porting effort, which is already being spent on maintaining their own ports. Besides STLPort with its dozen of patches, for example, there is ICU, with its own 6 plus, JPEG with 7, etc.

Now, I may be FreeBSD-centric, but even on Linux, where OOo themselves build, there are different distros with different packaging strategies and their own teams of capable people working on adding improvements, security and other bug-fixes (both their distro-specific and general purpose) to the ported software. Does OOo's version of ICU support KOI8-U? How many security bugs where found in OpenSSL since the last release of OOo?

OOo should be using these people's efforts, not fighting them. And your mother has nothing to do with it.

OpenOffice is targeted at people like my mother writing documents for their work.

Your mother will not be able to build from source anyway. She would have to use pre-built binaries -- in the form of RPMs or BSD packages. Such packaging (whichever it is) allows to automatically install dependencies. Done.

I'm talking about building from source.

Wasting a little bit of space or bandwidth is simply not a problem any more these days.

So, you'd rather they package their own Java too? I mean, if the license allowed them to?

But you clearly don't even have a clue, of how much waste I'm talking about. The OOo_1.1.4_source.tar.gz is 219743Kb. Extracting it make 712218Kb. Of that at least 77044Kb is redundant right of the bat (and I'm sure, I missed something besides apache_java berkeleydb bitstream_vera_fonts boost curl dmake expat freetype icu jpeg libxml2 moz nas neon np_sdk openssl python regexp sablot sane sax stlport unixODBC unzip zlib.

Now, of those 712218Kb extracted, 34472Kb are BMP (!), PDF, HTML, PNG, JPG, and dictionary files. Plus 20723Kb of pre-built JARs. Even assuming that everything else is source, the redundancy is already at over 30% (219743 out of 712218-34472-20723=657023). JARs and .tar.gz-s don't compress well either, which explain the poor compression ratio of their releases -- the redundant crap accounts for even more bandwidth waste than for storage waste (less valuable resource, BTW).

Now, there is source and there is source. OOo bundles STLPort -- and several versions of it. Do you realize, what kind of a beast that is? And not so much in size as in time it takes to build it and the effort it takes to port it to a new platform (OOo does not build on FreeBSD/amd64, for example, one has to port it manually). Other packages they ship similarly require porting effort, which is already being spent on maintaining their own ports. Besides STLPort with its dozen of patches, for example, there is ICU, with its own 6 plus, JPEG with 7, etc.

Now, I may be FreeBSD-centric, but even on Linux, where OOo themselves build, there are different distros with different packaging strategies and their own teams of capable people working on adding improvements, security and other bug-fixes (both their distro-specific and general purpose) to the ported software. Does OOo's version of ICU support KOI8-U? How many security bugs where found in OpenSSL since the last release of OOo?

OOo should be using these people's efforts, not fighting them. And your mother has nothing to do with it.

OpenOffice is targeted at people like my mother writing documents for their work.

Your mother will not be able to build from source anyway. She would have to use pre-built binaries -- in the form of RPMs or BSD packages. Such packaging (whichever it is) allows to automatically install dependencies. Done.

I'm talking about building from source.

Wasting a little bit of space or bandwidth is simply not a problem any more these days.

So, you'd rather they package their own Java too? I mean, if the license allowed them to?

But you clearly don't even have a clue, of how much waste I'm talking about. The OOo_1.1.4_source.tar.gz is 219743Kb. Extracting it make 712218Kb. Of that at least 77044Kb is redundant right of the bat (and I'm sure, I missed something besides apache_java berkeleydb bitstream_vera_fonts boost curl dmake expat freetype icu jpeg libxml2 moz nas neon np_sdk openssl python regexp sablot sane sax stlport unixODBC unzip zlib.

Now, of those 712218Kb extracted, 34472Kb are BMP (!), PDF, HTML, PNG, JPG, and dictionary files. Plus 20723Kb of pre-built JARs. Even assuming that everything else is source, the redundancy is already at over 30% (219743 out of 712218-34472-20723=657023). JARs and .tar.gz-s don't compress well either, which explain the poor compression ratio of their releases -- the redundant crap accounts for even more bandwidth waste than for storage waste (less valuable resource, BTW).

Now, there is source and there is source. OOo bundles STLPort -- and several versions of it. Do you realize, what kind of a beast that is? And not so much in size as in time it takes to build it and the effort it takes to port it to a new platform (OOo does not build on FreeBSD/amd64, for example, one has to port it manually). Other packages they ship similarly require porting effort, which is already being spent on maintaining their own ports. Besides STLPort with its dozen of patches, for example, there is ICU, with its own 6 plus, JPEG with 7, etc.

Now, I may be FreeBSD-centric, but even on Linux, where OOo themselves build, there are different distros with different packaging strategies and their own teams of capable people working on adding improvements, security and other bug-fixes (both their distro-specific and general purpose) to the ported software. Does OOo's version of ICU support KOI8-U? How many security bugs where found in OpenSSL since the last release of OOo?

OOo should be using these people's efforts, not fighting them. And your mother has nothing to do with it.

I've been spoiled by GNU extensions to tools like grep and ls. Considering I spend most of my time in a command line (under a GNOME terminal, no less), I'd probably find myself frequently irritated.

Install the sysutils/coreutils port. You'll get all the GNU utilities with a 'g' prefix, i.e. gls, gcp, etc. You can alias the ones you want to use.

http://www.freshports.org/ If they work on FreeBSD for free, most of them can be persuaded with money to port to Linux as well -- it is not that much worse :-)

http://www.freshports.org/java/jdk15/ And yet here I found this. I guess they must be liars.

SKEM ( /usr/ports/mail/milter-skem on FreeBSD) will not eliminate spam, but it will throttle the volume of it arriving from rogue servers and hi-jacked PCs, while the worst effect of a false-positive is delayed (rather than rejected) legitimate e-mail.

he said easy-to-use. in general MPLAYER's transcode is a pain in the arse (at best) to get used to from say, a GUI point-n-click windows-like dvd ripper.

personally, i reccommend, dvdrip which isn't too shabby:
http://www.freshports.org/multimedia/dvdrip/

Coincidentally, The FreeBSD Project is evil.

Documentation is very easy to find and readily available for the BSDs:

NetBSD packages
OpenBSD packages
FreeBSD packages

DragonFly uses FreeBSDs ports at this time as per the FAQ

Also see FreshPorts

Gentoo(Linux, not BSD):
19384 ebuilds, 9440 Packages, Last Updated At 12:21:45 GMT

PkgSrc (NetBSD+):
Over 5400 packages

FreeBSD Freshports:
10897

I was unable to find stats for OpenBSD, but I last recall it was in the 2000 range.

Anywho, my point being, it contains about 1/2 of the packages that Gentoo has (and, let's be honest, a lot of the stuff in Gentoo is fluffy crap) and runs on platforms that it is dead-impossible to find decent apps for, like AIX.

http://www.freshports.org/converters/p5-Convert-Mo rse/

Perl module to convert to and from morse. Now for that 'open' phone that could run perl...

mDNSResponder has been part of FreeBSD Ports since March 03, 2004.

GNUstep has had (inofficial) support of Rendezvous (as it was known back then) since quite some time before the above mentioned date.

32 bit Wine (and Win32 apps) runs today on a AMD64 running a 64 bit distro if you have installed the 32 bit libs for your distro.

"since a gui install and gui version of pkg_* utilities would increase the appeal of FreeBSD."

You mean like bpm, portbrowser, or barry?

"since a gui install and gui version of pkg_* utilities would increase the appeal of FreeBSD."

You mean like bpm, portbrowser, or barry?

"since a gui install and gui version of pkg_* utilities would increase the appeal of FreeBSD."

You mean like bpm, portbrowser, or barry?

A FreeBSD-röl: nekem problémamentes. Elsösorban azért ez, mert nagyságrendekkel könnyebb volt megtanulni mint a linuxot. Kezdve a tüzfal konfigurációtól (ami angolul van - tényleg, megírni még egy bonyolultabb filtert is olyan, mintha angolul beszélnél) az oprencer konfigurációig. Aztán meg ott van a csomagkezelöje, mely ötvözi az APT és a ports funkcionalitását. pkg_add -r openoffice-2.0-devel az egyenlö az apt-get install openoffice-blah paranccsal. Szóval nem muszály ports-t használni, lehet teljesen a bináris csomagkezelöre hagyatkozni, amely funkcionalitását tekintve minden szempontból lefedi a debian csomagkezelöjét. A bináris csomakog relatíve frissek (kábé 1 hónap csúszás van a ports-hoz képest, de ezen még akarnak a jövöben javítani): xorg 6.8.2, kde 3.4, openoffice-2 (még a magyar verziója is!!!) stb.. Aztán ott van a webes infrastuktúrájuk. Lehetöség van feltölteni az installált portjaidat a a freshports-ra, és emailben értesítenek ha valamelyik csomagot frissítették.

Aztán: nem kell skipfirst meg ilyesmi. Mikor felteszel több portot, ha az egyik nem sikerül, egyszerüen továbblép, tehát nagyobb lelki nyugalommal hagyom ott hétvégére a gépet fordítani, mert mire megérkezem, ott lesz egy lista hogy miket installált, mik nem sikerültek, és hogy miért nem sikerültek. Aztán: a már felinstallált (mindegy hogy forrásból vagy binárisból) csomagokból egy paranccsal tudsz binárist csinálni: pkg_create -b pkg_name. Ez pedig pont olyan lesz mint egy .deb csomag: tartalmazza a csomag telepítéséhez szükséges dependenciák információit, tehát amikor egy másik gépre fel akarod tenni, automatikusan felteszi a dependenciát vagy az általad megadott útvonalról, vagy a netröl. Így telepítettem a két ratyi gépet is. A jobbikon telepítettem a csomagokat, -p kapcsolóval (mondjuk portinstall -p blackbox) - ami felteszi a csomagot és csinál egy bináris csomagot is egyben. Majd átmásoltam ftp-én keresztül a binárisokat a gyeng

Hasn't hit ports. :\

In my experience, ports doesn't lag too far behind portage - it's somewhere between the portage stable branch and current. As the complexity of a package (and it's impact on other ports) grows, so does the time port maintainers spend testing them. Just to give a good idea of how much ports is up to date (or not):

If we take the GIMP for example, usually it is in ports the day it is announced. That speaks volumes of it's portability/cleanness of the code base. On the other hand, as important as it may be, it doesn't affect much other ports.

Then let's see KDE. KDE becomes part of ports (and the package repository) usually a few weeks after the announcment. If I remember correctly, one of the 3.2 releases was in ports some 3-4 days after release. On the other hand, 3.3.2 took 2 week to get there. That isn't much of a lag, now is it?

And finally: Xorg. Xorg affects many many ports, so there is usually a lot more time spent in testing then with the packages I just mentioned. We are still at 6.8.1, although 6.8.2 is coming as you can see from this mailing list post.

Generally, ports is quite up to date. There are weekly updates to OpenOffice.org 2.0 - probably because it is independent from other ports. Also, the most important package are updated pretty fast (I had PHP 5.0.3 running before the announcment of the security fix release hit slashdot). Others, however, lag behind somewhat. We don't have KDE 3.4beta in ports for example, while I guess it is already in portage.

As I said, I don't disagree with what you wrote, I just wanted to give a general impression about the freshness of ports for other readers (check out freshports to learn more.

No, it cannot. There has been no demand for it, and that is why no one has gone to http://www.freshports.org/audio/faad/ and used this source to add the codec. However, if you want to, it shouldn't take to long to add this to the firmware.

On a fresh new installation you only have to enter the URL (preferably https), and the username/password to get it...

There is even an Apache mod complete with FreeBSD ports thereof.

Software: most software written for linux would compile without much change on FreeBSD. In fact, that's how the ports system work. Check out freshports to see if your favourite app is included or not. You can also have binary packages, which can be installed similarly to debian packages (pkg_add -r blah is ~ apt-get install blah). If you put linux_enable="YES" into your rc.conf, you'll have linux 'emulation.' Don't worry, it's not really an emulation, linux-apps run with native speed on FreeBSD. Really. (you can try it yourself if you don't believe me, for sometimes there exists both a native freebsd and a linux version of the same program). Finding an app is as simple as cding into /usr/ports and typing "make search name=[progname]" if you know the name of the application you need or "make search key=[whatever]" to search in the short descriptions of each port. Installing that app is as simple as entering it's directory, and typing make install clean (or if you have portupgrade tool installed, you can simply say: portinstall mplayer. Details in the handbook :)

I also have slack on my puter btw (with kernel 2.6.7), and now that ULE is turned off, slack seems to be slightly faster on the desktop (KDE on both), but only if the system is heavily loaded. I think, even for someone who is new to FreeBSD, tracking -STABLE (look up what that means in the handbook is pretty safe, and hopefully they will reenable the new ULE constant time scheduler (whatever that means, I just read this fancy description on OSNEWS :o)) soon.

Hardware compatibility: FreeBSD supports standard pc hardware. There are accelerated binary native nvidia drivers for freebsd. USB support is excellent (my USB mouse worked out of the box, just read the installation messages carefully - you have to say no to mouse configuration if you have an usb mouse) ... except for USB 2.0. So USB 2.0 devices work in 1.1 compatibility mode. Discussion, however, is already started for fixing USB 2.0 support (EHCI driver), and I'm sure it will be ready soon. I also have a tv card (PlayTV MPEG2, an el cheapo card) which works nicely under FreeBSD and with mencoder (and FreeBSD's own native tv app, fxtv). In fact, I have much clearer picture than on windows, thanks to better filters in mplayer I think. This is the command I use to get the best quality btw:

mplayer tv:// -tv input=1:driver=bsdbt848:norm=palbg:audioid=2 \
-vf pp=hb/vb/dr/al/lb,hqdn3d -stop-xscreensaver

Did they just say "entirely in C" and "assured of predictable behavior" in the same context?

o_0

The only thing better than writing everything in C is how it supports BEOS and OS/2!

on freebsd 5.2.1.... APR is required to build:
devel/gmake
devel/automake18
devel/autoconf259
devel/libtool15

so I guess most people don't even realize that APR is one of the fundamental building blocks of all open source applications.

Its too bad it only incldes basic low-level data structure functionality so far.

list of all APR modules

But then again I guess that's the point of this project. Anything to make C coders lives easier is a good thing!

Did they just say "entirely in C" and "assured of predictable behavior" in the same context?

o_0

The only thing better than writing everything in C is how it supports BEOS and OS/2!

on freebsd 5.2.1.... APR is required to build:
devel/gmake
devel/automake18
devel/autoconf259
devel/libtool15

so I guess most people don't even realize that APR is one of the fundamental building blocks of all open source applications.

Its too bad it only incldes basic low-level data structure functionality so far.

list of all APR modules

But then again I guess that's the point of this project. Anything to make C coders lives easier is a good thing!

Did they just say "entirely in C" and "assured of predictable behavior" in the same context?

o_0

The only thing better than writing everything in C is how it supports BEOS and OS/2!

on freebsd 5.2.1.... APR is required to build:
devel/gmake
devel/automake18
devel/autoconf259
devel/libtool15

so I guess most people don't even realize that APR is one of the fundamental building blocks of all open source applications.

Its too bad it only incldes basic low-level data structure functionality so far.

list of all APR modules

But then again I guess that's the point of this project. Anything to make C coders lives easier is a good thing!

Did they just say "entirely in C" and "assured of predictable behavior" in the same context?

o_0

The only thing better than writing everything in C is how it supports BEOS and OS/2!

on freebsd 5.2.1.... APR is required to build:
devel/gmake
devel/automake18
devel/autoconf259
devel/libtool15

so I guess most people don't even realize that APR is one of the fundamental building blocks of all open source applications.

Its too bad it only incldes basic low-level data structure functionality so far.

list of all APR modules

But then again I guess that's the point of this project. Anything to make C coders lives easier is a good thing!

As I said in another post, a big side effect is that zsh's completions seem to be much faster than bash's. That alone is worth the price of admission for me.

These "legions of geeks and developers" are just whiners -- the source was always there. If you needed it, you could do it -- the whole point of the open source, right?

lets play a game... who can find the oldest CVS gui?

further than all that... even the binary license is strict; if you distribute the SUN java in your OS distro... then you are not allowed to distribute ANY other replacement

Not sure, what you mean... FreeBSD now offers installable binary packages for both JRE and JDK. But Kaffe is also offered, as is gcj (as part of any gcc port from the lang group).

What Sun understandably wishes to avoid is the situation, when the Java code has to start checking, which JVM is in use to work around bugs or to offer different features. This was the whole point of their suit against Microsoft. And GNU is quite prone to introducing its own "embrace-and-extensions", viz. gcc, gawk, etc.

making it "free" (as in freedom) and GPL compatible would be a tremendous step

It would be -- from the political point of view. Technically -- I don't care.

further than all that... even the binary license is strict; if you distribute the SUN java in your OS distro... then you are not allowed to distribute ANY other replacement

Not sure, what you mean... FreeBSD now offers installable binary packages for both JRE and JDK. But Kaffe is also offered, as is gcj (as part of any gcc port from the lang group).

What Sun understandably wishes to avoid is the situation, when the Java code has to start checking, which JVM is in use to work around bugs or to offer different features. This was the whole point of their suit against Microsoft. And GNU is quite prone to introducing its own "embrace-and-extensions", viz. gcc, gawk, etc.

making it "free" (as in freedom) and GPL compatible would be a tremendous step

It would be -- from the political point of view. Technically -- I don't care.

further than all that... even the binary license is strict; if you distribute the SUN java in your OS distro... then you are not allowed to distribute ANY other replacement

Not sure, what you mean... FreeBSD now offers installable binary packages for both JRE and JDK. But Kaffe is also offered, as is gcj (as part of any gcc port from the lang group).

What Sun understandably wishes to avoid is the situation, when the Java code has to start checking, which JVM is in use to work around bugs or to offer different features. This was the whole point of their suit against Microsoft. And GNU is quite prone to introducing its own "embrace-and-extensions", viz. gcc, gawk, etc.

making it "free" (as in freedom) and GPL compatible would be a tremendous step

It would be -- from the political point of view. Technically -- I don't care.

further than all that... even the binary license is strict; if you distribute the SUN java in your OS distro... then you are not allowed to distribute ANY other replacement

Not sure, what you mean... FreeBSD now offers installable binary packages for both JRE and JDK. But Kaffe is also offered, as is gcj (as part of any gcc port from the lang group).

What Sun understandably wishes to avoid is the situation, when the Java code has to start checking, which JVM is in use to work around bugs or to offer different features. This was the whole point of their suit against Microsoft. And GNU is quite prone to introducing its own "embrace-and-extensions", viz. gcc, gawk, etc.

making it "free" (as in freedom) and GPL compatible would be a tremendous step

It would be -- from the political point of view. Technically -- I don't care.

Is it really that important to be able to distribute the built binaries for people? Without paying Sun for it, that is?

Is it really that important to be able to distribute the built binaries for people? Without paying Sun for it, that is?

Am I the only one who's getting tired of trying to play matchup with GLIBC versions?

Switch to FreeBSD and petition WINE to follow. If FreeBSD becomes their primary platform, vendors of the various distros will become responsible for porting WINE.

As it stands, FreeBSD wine-port end up having to untangle various hacks put in for Linux' sake.

**** THE PROOF THAT D.O.U.O.S.V.A.V.V.M. IS EVIL ****

D O U O S V A V V M
68 79 85 79 83 86 65 86 86 77 - as ASCII values
5 7 4 7 2 5 2 5 5 5 - digits added
\_____/ \_____/ \_____/ \_____/ \_____/
3 2 7 7 1 - digits added

Thus, "D.O.U.O.S.V.A.V.V.M." is 32771.

Turn the number backwards, and add 1834 - the year Vesuvius erupted.
The number is now 19557.

Subtract 4591 from the number - this is the year Elvis recorded his
debut single, putting the end to all morality and good taste, written
backwards. It gives 14966.

Subtract 7, the sacred number of Illuminati. The result will be 14959.

Add 7691 to it - this is the year Che Guevara was executed in Bolivia,
written backwards - you will get 22650.

Turn the number backwards, subtract 1952 - the year killer fog haunted
London. The number is now 3670.

This number, read as octal, gives 1976 - the year George Harrison
performed the lumberjack song with Monty Python - if you have seen it,
you should understand.

This is truly evil. QED.

ps. 6+8=14=>1+4=5