No, they'd kill one flight attendant, then grab another one by the neck and ask "Who wants to come up and be next."
All the little wanna be heroes would remain seated.
Doubtful. Even *I* can see that a planeload of people can overpower five? ten? attackers. If we can play up the passenger's fears of riding around in the guts of an extra-large missile, we can get them up and striking back.:D
To wit: I hand you a router. I assure you that you can put your unpatched Windows boxes behind this router, and it will protect them. I tell you that you can hook the other side of this router to the Internet and it will continue to protect those boxes from all threats. My assurances are nothing more than empty promises, as this router exposes each box that you attach to it directly to the Internet.
They would be trying to decrypt 40GB of random data. No password that they could beat out of me would work, as there's nothing to decrypt!
So, here's the scenario that you're imagining, I guess: a) Cops confiscate my machine b) Cops find 40GB of random data c) Cops think that that's encrytped data d) Cops ask me for a password e) I say "There is no password." f) They beat me until I die???
That sort of thing is not supposed to happen in the Free World (TM).
The point is, if an adversary knows that you have a TrueCrypt Hidden OS, then it's no more secure than a plain old TrueCrypt-encrypted partition.
Aye. But if your adversary *really* *strongly* *believes* that you have a TrueCrypt Hidden OS where one does not actually exist, they're gonna wander off on a very expensive and time consuming snipe hunt.
A bug with *my* card/drivers and the cards of some dozens of other players? Not likely.:)
Also, I'm quite happy with the kit that I have ATM. It'll play everything but Crysis based games. I'd rather spend the money on networking gear, storage, and good manuals.
QFT, unless you're playing on a console or on the PC version with the graphics turned all the way down
Radeon X800 AGP (256MB RAM), graphics at medium or high. The flashlights of other players are translucent cones at the end of their weapon when active; they do not illuminate their surroundings.
All of the in-game folks that I've talked to have *never* had their environment illuminated by a teammate's flashlight.
h) If the desktop is where the Linux community has decided it wants to go, Linus needs to be brought into line with that vision.
Tell me again why the preemptive kernel patches were merged into mainline? How about the kernel modesetting patches? Why is the CFQ scheduler set as the default, rather than the deadline scheduler?
If you want the i386 client desktop, that is where you need to put the entirety of your focus. Forget portability, forget the server, and focus purely on being an i386 client desktop.
Thank $DEITY that this isn't a priority of the kernel.org folks. 'Cause if it was, Linux would not run on AMD64 systems in 64-bit mode. IDK about you, but I see a day that's not too far off where the vast majority of desktop systems are AMD64 based.
Simple example: what about networked players? * Do you add a switch into the unit and have both the TV and the player on the same subnet/VLAN? Or does the player and TV have its own subnet and the unit acts as a router?
If we assume that these devices are going to be on Joe Average's network, then we do nothing fancy... behave just like any PC attached to the network would behave.
[Should the player be a router o]r should the TV?
Neither, unless one really *wanted* to make them a router, I would make them a switch. I suppose that you could advertise your network-enabled media device as a handy-dandy router, for those folks who can't be arsed to buy a $30 router + WAP. But then, you'd need to add an IP stack to the devices in question.
Which address space should it pick? What if it clashes with the existing network?
Use DHCP to figure this out. If there are no DHCP servers, turn to the procedures outlined in RFC 3927.
What if there are duplex negotiation bugs/issues?
I imagine that duplex/rate negotiation is a solved problem by now. Have you seen issues caused by non-broken hardware that would not negotiate rate or duplex settings?
Er... a) Why not use plain-old Ethernet for the data transfer between the TV and the video output device, and say "Thou shalt do nothing but run the cable between the TV and the video output device."? b) Explain to me again how two different frames on a link on a LAN can travel differing paths from the same source to the same destination? We *are* assuming that you're not piping your home theater stuff over the Internet, yes? We are also assuming that the BOFH isn't changing the network topology on the fly, yes?
Instead of needing 1GB of libraries to run Amarok...
$ cd ~/kde && ldd bin/amarok | grep/home/me/kde | sed -e 's/.*=> \(.*\) (.*/\1/' > file.txt $ #Remove newlines from file.txt, and place 'du -schD' in front of the line $ bash file.txt 45M/home/me/kde/lib/libkdeui.so.5 72M/home/me/kde/lib/libamaroklib.so.1 23M/home/me/kde/lib/libkdecore.so.5 3.5M/home/me/kde/lib/libkutils.so.4 103M/home/me/kde/lib/libkhtml.so.5 6.4M/home/me/kde/lib/libkfile.so.4 1.7M/home/me/kde/lib/libthreadweaver.so.4 5.7M/home/me/kde/lib/libknewstuff2.so.4 6.6M/home/me/kde/lib/libphonon.so.4 21M/home/me/kde/lib/libplasma.so.3 9.7M/home/me/kde/lib/libsolid.so.4 1.1M/home/me/kde/lib/libtag.so.1 404K/home/me/kde/lib/libtag-extras.so.0 965K/home/me/kde/lib/libamarokpud.so.1 176K/home/me/kde/lib/libmediadevicelib.so.1 7.5M/home/me/kde/lib/libkjs.so.4 2.4M/home/me/kde/lib/libkparts.so.4 37M/home/me/kde/lib/libkio.so.5 2.5M/home/me/kde/lib/libktexteditor.so.4 585K/home/me/kde/lib/libstreams.so.0 1.4M/home/me/kde/lib/libstreamanalyzer.so.0 347M total
FYI: These libs were built unoptimized on a 32-bit x86 system, with full debug symbols. Your libs will be at least 50% -and probably 75-80%- smaller.
Or, if you want to include *all* of the libs, remove the invocation of grep from the previous instructions and you get:
$ bash file.txt # Details of libs elided to appease the damn lameness filter. # Be aware that *every* lib on the system, including QT4 is in this listing. 382M total
This is a fair bit shy of 1GB of libs. If Amarok really requires 1GB of libs on your system, you might want to let your packager know that they're doing something wrong.
Yes, that means binary compatibility must stop being broken from OS update to OS update.
Hi. I just installed version 25034 of Loki's Linux port of Tribes 2 on one of my Unstable X86 Gentoo Linux machine. This is a seven-year-old binary-only userspace application. It works just as well as when I first installed it those many years ago.
$ uname -srmpi Linux 2.6.29-tuxonice-r2 i686 Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz GenuineIntel
Or were you talking about kernel-level ABI compatibility? Not gonna happen, ever. However, it's *not* hard for out-of-kernel module maintainers to recompile and redeliver their module for a new rev of the kernel. Hell, it's not hard for them to keep up with changes to the kernel API... I should know, I maintained my own local copy of pcc-acpi-0.8.4 for a little more than two years.
Slashdot Mirror
No, they'd kill one flight attendant, then grab another one by the neck and ask "Who wants to come up and be next."
All the little wanna be heroes would remain seated.
Doubtful. Even *I* can see that a planeload of people can overpower five? ten? attackers. If we can play up the passenger's fears of riding around in the guts of an extra-large missile, we can get them up and striking back. :D
Assurances are not security.
To wit:
I hand you a router. I assure you that you can put your unpatched Windows boxes behind this router, and it will protect them. I tell you that you can hook the other side of this router to the Internet and it will continue to protect those boxes from all threats.
My assurances are nothing more than empty promises, as this router exposes each box that you attach to it directly to the Internet.
Happy Saturday!
On top of that, he will have a tounge...
Tongue. The word that you are looking for is tongue.
Please re-read this, I think that you've gotten off track.
http://slashdot.org/comments.pl?sid=1255875&cid=28203033
They would be trying to decrypt 40GB of random data. No password that they could beat out of me would work, as there's nothing to decrypt!
So, here's the scenario that you're imagining, I guess:
a) Cops confiscate my machine
b) Cops find 40GB of random data
c) Cops think that that's encrytped data
d) Cops ask me for a password
e) I say "There is no password."
f) They beat me until I die???
That sort of thing is not supposed to happen in the Free World (TM).
I subscribe to the JFDI method of development. ;)
What are they going to do with that wrench? Beat me until I lie?
The point is, if an adversary knows that you have a TrueCrypt Hidden OS, then it's no more secure than a plain old TrueCrypt-encrypted partition.
Aye. But if your adversary *really* *strongly* *believes* that you have a TrueCrypt Hidden OS where one does not actually exist, they're gonna wander off on a very expensive and time consuming snipe hunt.
*points to his ~40GB of random numbers*
Wanna try to discover the password for that, Officer?
A bug with *my* card/drivers and the cards of some dozens of other players? Not likely. :)
Also, I'm quite happy with the kit that I have ATM. It'll play everything but Crysis based games. I'd rather spend the money on networking gear, storage, and good manuals.
QFT, unless you're playing on a console or on the PC version with the graphics turned all the way down
Radeon X800 AGP (256MB RAM), graphics at medium or high. The flashlights of other players are translucent cones at the end of their weapon when active; they do not illuminate their surroundings.
All of the in-game folks that I've talked to have *never* had their environment illuminated by a teammate's flashlight.
It seems to me that jail-busting bugs in BSD's kernel are much less likely than sandbox-busting bugs in VMWare's software.
Disable JavaScript and the image goes away.
Actually, the site w/out JS is only slightly faster than Google over IPv6 with JS enabled.
Have you read his follow-on comment?
http://slashdot.org/comments.pl?sid=1252121&cid=28173153
Here's the money quote:
There were several long-standing bugs caused by reader threads getting their data while another thread was halfway through an update.
That behaviour can't be intentional. :)
What do you think about the "generic programming" capabilities that the STL and C++ templates allow?
(Pardon my English, I haven't had my coffee yet.)
*points to his later comment*
http://slashdot.org/comments.pl?sid=1252121&cid=28168729
Bug reports are not appreciated, but ignored.
That depends on the project and the attitude of the contributor. :)
e) Standardise around pkgsrc for package management.
How is pkgsrc better than ports and/or portage?
h) If the desktop is where the Linux community has decided it wants to go, Linus needs to be brought into line with that vision.
Tell me again why the preemptive kernel patches were merged into mainline? How about the kernel modesetting patches? Why is the CFQ scheduler set as the default, rather than the deadline scheduler?
If you want the i386 client desktop, that is where you need to put the entirety of your focus. Forget portability, forget the server, and focus purely on being an i386 client desktop.
Thank $DEITY that this isn't a priority of the kernel.org folks. 'Cause if it was, Linux would not run on AMD64 systems in 64-bit mode. IDK about you, but I see a day that's not too far off where the vast majority of desktop systems are AMD64 based.
(Does the Linux world even have visual IDEs for window layout... at all?)
FLUID (FLTK)
QT Creator (QT)
GLADE (GTK)
WxDevCpp (WxWidgets)
Any one of the numerous GUI builders that plug into Eclipse
I'm sure that there are others, I can't be arsed to find em.
and you would be looking at like ~400MB just to use a 30MB app.
I daresay that even *this* new number of yours is too high:
http://slashdot.org/comments.pl?sid=1250893&cid=28154469
Audio and about 30 other areas have major issues that have hung around far too long because of no concise direction or unity.
What are the roughly thirty other areas and what are their issues?
Simple example: what about networked players?
* Do you add a switch into the unit and have both the TV and the player on the same subnet/VLAN? Or does the player and TV have its own subnet and the unit acts as a router?
If we assume that these devices are going to be on Joe Average's network, then we do nothing fancy... behave just like any PC attached to the network would behave.
[Should the player be a router o]r should the TV?
Neither, unless one really *wanted* to make them a router, I would make them a switch. I suppose that you could advertise your network-enabled media device as a handy-dandy router, for those folks who can't be arsed to buy a $30 router + WAP. But then, you'd need to add an IP stack to the devices in question.
Which address space should it pick? What if it clashes with the existing network?
Use DHCP to figure this out. If there are no DHCP servers, turn to the procedures outlined in RFC 3927.
What if there are duplex negotiation bugs/issues?
I imagine that duplex/rate negotiation is a solved problem by now. Have you seen issues caused by non-broken hardware that would not negotiate rate or duplex settings?
Er...
a) Why not use plain-old Ethernet for the data transfer between the TV and the video output device, and say "Thou shalt do nothing but run the cable between the TV and the video output device."?
b) Explain to me again how two different frames on a link on a LAN can travel differing paths from the same source to the same destination? We *are* assuming that you're not piping your home theater stuff over the Internet, yes? We are also assuming that the BOFH isn't changing the network topology on the fly, yes?
Instead of needing 1GB of libraries to run Amarok...
$ cd ~/kde && ldd bin/amarok | grep
$ #Remove newlines from file.txt, and place 'du -schD' in front of the line
$ bash file.txt
45M
72M
23M
3.5M
103M
6.4M
1.7M
5.7M
6.6M
21M
9.7M
1.1M
404K
965K
176K
7.5M
2.4M
37M
2.5M
585K
1.4M
347M total
FYI: These libs were built unoptimized on a 32-bit x86 system, with full debug symbols. Your libs will be at least 50% -and probably 75-80%- smaller.
Or, if you want to include *all* of the libs, remove the invocation of grep from the previous instructions and you get:
$ bash file.txt
# Details of libs elided to appease the damn lameness filter.
# Be aware that *every* lib on the system, including QT4 is in this listing.
382M total
This is a fair bit shy of 1GB of libs. If Amarok really requires 1GB of libs on your system, you might want to let your packager know that they're doing something wrong.
Yes, that means binary compatibility must stop being broken from OS update to OS update.
Hi. I just installed version 25034 of Loki's Linux port of Tribes 2 on one of my Unstable X86 Gentoo Linux machine. This is a seven-year-old binary-only userspace application. It works just as well as when I first installed it those many years ago.
$ uname -srmpi
Linux 2.6.29-tuxonice-r2 i686 Intel(R) Core(TM) Duo CPU L2400 @ 1.66GHz GenuineIntel
Or were you talking about kernel-level ABI compatibility? Not gonna happen, ever. However, it's *not* hard for out-of-kernel module maintainers to recompile and redeliver their module for a new rev of the kernel. Hell, it's not hard for them to keep up with changes to the kernel API... I should know, I maintained my own local copy of pcc-acpi-0.8.4 for a little more than two years.
Would you mind pointing us to your test results?