Sorry don’t agree For me any software solution is worrthless
because there is always a way around it!
Only hardware protection can prevent this
and this is what the next generation PC’s will have
no software will be able to defeat it because they don’t run the show - it’s the hardware that will run the show!
Salutations
Salutations
How on EARTH can hardware stop something like virus which gain access to a computer almost exclusively via software?
Just because the hardware is fast doesn’t mean that it can magically stop hackers.
Every single system has a flaw.
Is this a joke?
We are so far away from the original pint i was making that i put a stop now
Tanks anyway
…how are we far away from the original point? Is this just a lame way of dodging valarking’s question? He makes a good (and true) point. Seriously, you have had no proof that anything that you said here is true. And work on your English.
Tanks anyway
Right. He should have said : Isn’t that viri?
And work on your English.
A bit harsh if English isn’t his first language, don’t you think?
Everyone’s probably just reacting to the Micro$oft propaganda that he’s spreading.
The fact is, once users find out how limiting trusted computing is, their probably switch over in droves to Mac/Linux. I don’t mind buying an OS. I just can’t stand the concept that the company I bought it from doesn’t trust me.
By the way, as far as needing a fast computer for security goes, there’s a OS called OpenBSD, what is it known for? Only one remote hole in the default install, in more than 10 years! That’s true security. And i’ve seen it run on 200mhz PII computers! Any multi-platform programmer will tell you that Windows is the most insecure, hacked up, worthless, mash together, excuse for an OS ever. Windows is so full of holes, it’s not even funny.
See this link on trusted computing
i realize this isn’t related at all to this but if someone can do this: http://www.youtube.com/watch?v=2SdGkkp1aq8 with a VIC-20, it’s clearly the huge geeks that run the show, not hardware.
Isn’t sarcasm an adverb?
That doesn’t change anything 
If you’re on an English forum, you have to speak proficiently. Otherwise use an online translator (Google, anyone?)
Nope, it’s a noun
How’s your spanish, italian and french?
i agree with that.
Assez bien
Being a Windows User(not proud or anything, it just happens to be cheapest), I think that the Trusted thing is wacked. Ive used Vista before(tho Im still using XP as of now), and the new security stuff is all a bunch of crap. By asking me a million questions, I dont feel any safer(rather, I feel quite violated. Doesnt my computer trust me?)
So, yeah.
Oh, and Linux is great if your a coder. If not, It can be a pain, what with all the compiling etc. I’d opt for OSX any day…
what’s so tough about
./configure
make
sudo make install
“make” is such a handy tool… it isnt necessarily just for compiling… you can use makefiles to do other common commands too, like TAR’ing folders
Last time I installed Ubuntu I didn’t have to compile a thing to get it working. Same for Sabayon (best distro imo), and SuSE.
One of the valid arguments for TC is that hardware can help protect against viruses. But, like VK said, nothing is foolproof. Unfortunately, TC makes it harder to fix against fools. (This is all explained quite well in the article twice referenced here. It did gloss over or twist a few things about computer security though --such as when it stated that PK is absolutely safe [which it most definitely is not].)
This is:
<b>/g/duoas/in/prog/libconfig/libconfig-1.0.1/ $</b> ./configure
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... .exe
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for ranlib... ranlib
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking for a sed that does not truncate output... /bin/sed
checking for egrep... grep -E
checking for ld used by gcc... C:/PROGRA~1/MinGW/mingw32/bin/ld.exe
checking if the linker (C:/PROGRA~1/MinGW/mingw32/bin/ld.exe) is GNU ld... yes
checking for C:/PROGRA~1/MinGW/mingw32/bin/ld.exe option to reload object files... -r
checking for BSD-compatible nm... /mingw/bin/nm
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic file format pei*-i386(.*architecture: i386)?
checking for dlltool... dlltool
checking for as... as
checking for objdump... objdump
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether accepts -g... no
checking the maximum length of command line arguments... 8192
checking command to parse /mingw/bin/nm output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... (cached) ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -DDLL_EXPORT
checking if gcc PIC flag -DDLL_EXPORT works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (C:/PROGRA~1/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes
checking whether -lc should be explicitly linked in... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... C:/PROGRA~1/MinGW/mingw32/bin/ld.exe
checking if the linker (C:/PROGRA~1/MinGW/mingw32/bin/ld.exe) is GNU ld... yes
checking whether the g++ linker (C:/PROGRA~1/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes
checking for g++ option to produce PIC... -DDLL_EXPORT
checking if g++ PIC flag -DDLL_EXPORT works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (C:/PROGRA~1/MinGW/mingw32/bin/ld.exe) supports shared libraries... yes
checking dynamic linker characteristics... Win32 ld.exe
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking for flex... no
checking for lex... no
checking for yywrap in -lfl... no
checking for yywrap in -ll... no
checking for bison... no
checking for byacc... no
checking for compiler switch to enable full warnings... -Wall
checking for ANSI C header files... (cached) yes
checking for unistd.h... (cached) yes
checking for stdint.h... (cached) yes
checking for an ANSI C-conforming const... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
configure: creating ./config.status
config.status: creating Makefile
config.status: creating doc/Makefile
config.status: creating samples/Makefile
config.status: creating samples/c/Makefile
config.status: creating samples/c++/Makefile
config.status: creating libconfig.pc
config.status: creating libconfig++.pc
config.status: creating ac_config.h
config.status: executing depfiles commands
<b>/g/duoas/in/prog/libconfig/libconfig-1.0.1/ $ </b>make
make all-recursive
make[1]: Entering directory `/g/duoas/in/prog/libconfig/libconfig-1.0.1'
Making all in .
make[2]: Entering directory `/g/duoas/in/prog/libconfig/libconfig-1.0.1'
if /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -DPARSER_PREFIX=\"libconfig_yy\" -D_REENTRANT -g -O2 -Wall -MT libconfig_la-libconfig.lo -MD -MP -MF ".deps/libconfig_la-libconfig.Tpo" -c -o libconfig_la-libconfig.lo `test -f 'libconfig.c' || echo './'`libconfig.c; \
then mv -f ".deps/libconfig_la-libconfig.Tpo" ".deps/libconfig_la-libconfig.Plo"; else rm -f ".deps/libconfig_la-libconfig.Tpo"; exit 1; fi
mkdir .libs
gcc -DHAVE_CONFIG_H -I. -I. -I. -DPARSER_PREFIX=\"libconfig_yy\" -D_REENTRANT -g -O2 -Wall -MT libconfig_la-libconfig.lo -MD -MP -MF .deps/libconfig_la-libconfig.Tpo -c libconfig.c -DDLL_EXPORT -DPIC -o .libs/libconfig_la-libconfig.o
gcc -DHAVE_CONFIG_H -I. -I. -I. -DPARSER_PREFIX=\"libconfig_yy\" -D_REENTRANT -g -O2 -Wall -MT libconfig_la-libconfig.lo -MD -MP -MF .deps/libconfig_la-libconfig.Tpo -c libconfig.c -o libconfig_la-libconfig.o >/dev/null 2>&1
make[2]: *** [libconfig_la-libconfig.lo] Error 1
make[2]: Leaving directory `/g/duoas/in/prog/libconfig/libconfig-1.0.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/g/duoas/in/prog/libconfig/libconfig-1.0.1'
make: *** [all] Error 2
<b>/g/duoas/in/prog/libconfig/libconfig-1.0.1/ $</b>
This is the point where I type
cd ../..
rd -rf libconfig
The problem is that configure, automake, make, etc. are not the perfect, universal tools people like to believe them to be. Particularly if they are used in a boilerplate way like the people who write libconfig did. Notice, for example, how many times we checked to see whether or not I had g++ and other GCC tools installed? Notice the long list of checks for random GCC languages? Notice the number of times it checked to see if my linker was the GNU ld? Etc. Notice also that the configure script terminated successfully but the make script failed abysmally.
Now I’m sufficiently experienced to know that most of that make verbiage is from a single command, but that’s because, as a programmer, I’ve made my own Makefiles and configure scripts and the like, and can follow the output somewhat. This output confuses me (that is, I’d have to spend some time figuring out what the heck that huge command was trying to do [obviously it was trying to do too many things at once] before I could even consider trying to repair it). It’s worth my time to roll my own code to do what libconfig is supposed to do.
This is, just like this post (and I hope you get it), waaaay overboard for most people to care about. Read the first and last sentence and delete the rest.
\me puts soapbox away
I actually like the current trend in apt-get type things, but it’s still no panacea. People like Windows because it tends to work straight out of the box. Linux has a much higher learning curve. (I’m personally not against it, but I don’t very accurately represent the vast cohort of home computer users.)
Bet your Xhosa is a bit rusty though.
Usaphela?