Quantcast KVCD in Linux - digitalFAQ.com Forums [Archives]
  #1  
12-05-2003, 02:38 AM
russiansexpat russiansexpat is offline
Free Member
 
Join Date: Nov 2003
Posts: 123
Thanks: 0
Thanked 0 Times in 0 Posts
http://www.kvcd.net/forum/viewtopic.php?t=7771
__________________
are you ready for year 2038?
x+2038-1970 > (2^31+1)/(365.25*24*3600)
/dev/mem < /dev/null
Reply With Quote
Someday, 12:01 PM
admin's Avatar
Site Staff / Ad Manager
 
Join Date: Dec 2002
Posts: 42
Thanks: ∞
Thanked 42 Times in 42 Posts
  #2  
12-31-2003, 03:40 AM
rendalunit rendalunit is offline
Free Member
 
Join Date: Apr 2002
Location: san jose, Ca
Posts: 1,148
Thanks: 0
Thanked 0 Times in 0 Posts
What is the reference to year 2038 about?

Just wondering,
thanks
Reply With Quote
  #3  
12-31-2003, 06:18 AM
Dialhot Dialhot is offline
Free Member
 
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by rendalunit
What is the reference to year 2038 about?
A lot of programs are coded in C or C++ language. In these (and others language) time and date are coded as number of second spent since the EPOCH (the time reference that is 01/01/1970).

Since the time is coded on 32 bits, you can have only 2^32 seconds before to have a general reset of all time based programs ! And the lethal date is in 2038 (you can count )

Thats will be a HUGE bug, far larger than the Year 2K one.
Reply With Quote
  #4  
12-31-2003, 01:27 PM
rendalunit rendalunit is offline
Free Member
 
Join Date: Apr 2002
Location: san jose, Ca
Posts: 1,148
Thanks: 0
Thanked 0 Times in 0 Posts
ah Thanks

That does sound like a bad bug
Reply With Quote
  #5  
01-01-2004, 10:45 AM
Dialhot Dialhot is offline
Free Member
 
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by rendalunit
That does sound like a bad bug
Not really : the 64bits CPU are coming and before 2038 they probably be 128 or 256. All the program will be compiled in 64 bit mode at least and the reference size for an integer (that is set to 32 bits nowaday) will be probably fixed to 64 bits also. So the 2038 problem will disappear.
Reply With Quote
  #6  
01-01-2004, 12:57 PM
ak47 ak47 is offline
Free Member
 
Join Date: Oct 2002
Posts: 168
Thanks: 0
Thanked 0 Times in 0 Posts
Kinda sounds like a scam to get out of 32-bit CPUs. To bad that the date isn't closer, since 64-bit now is out.
__________________
Later ak
Reply With Quote
  #7  
01-06-2004, 09:57 AM
russiansexpat russiansexpat is offline
Free Member
 
Join Date: Nov 2003
Posts: 123
Thanks: 0
Thanked 0 Times in 0 Posts
Hopefully technology change before 2038.
Still we are flying on average 30 years old airplains.
Just to recomple application programs is not always possible - source code went to trash bins and developers gone fishing or do some gardering.
2^31+1 in fact in kernels, not like in Y2K applications and these kernels in many situations are embedded.
Somebody will have some fun around 18 January 2038, especially because most of the teens nowdays have no idea even how electricity works.
__________________
are you ready for year 2038?
x+2038-1970 > (2^31+1)/(365.25*24*3600)
/dev/mem < /dev/null
Reply With Quote
  #8  
01-06-2004, 10:17 AM
Dialhot Dialhot is offline
Free Member
 
Join Date: May 2003
Posts: 10,463
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by ak47
Kinda sounds like a scam to get out of 32-bit CPUs. To bad that the date isn't closer, since 64-bit now is out.
Don't worry about that : we are already doing all our applications in 64 bits. And I do not think my company is the only one to do that
Reply With Quote
  #9  
01-06-2004, 04:50 PM
ak47 ak47 is offline
Free Member
 
Join Date: Oct 2002
Posts: 168
Thanks: 0
Thanked 0 Times in 0 Posts
Thats your company, but there is no video game for the pc yet that supports 64-bit, I think, also barly any 64-bit video encoders.
__________________
Later ak
Reply With Quote
  #10  
01-06-2004, 05:30 PM
BobNET BobNET is offline
Free Member
 
Join Date: Sep 2003
Location: Ontario, Canada
Posts: 67
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to BobNET
Quote:
Originally Posted by ak47
but there is no video game for the pc yet that supports 64-bit, I think, also barly any 64-bit video encoders.
Chicken and egg problem... very few people have 64-bit processors, so no one writes software for them. But since there's no software, no one has a reason to get a 64-bit processor!

But... Linux already runs in 64-bit mode on AMD64 (Opteron, Athlon64) processors (and soon FreeBSD and NetBSD will, too). So people running Linux on an AMD64 just have to recompile mencoder and instantly get a 64-bit video encoder (it might not take full advantage of the larger data path, but should still be faster than a 32-bit-compiled version).
__________________
--
Chris "Bob" Odorjan
Reply With Quote
  #11  
01-06-2004, 06:22 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
NetBSD was the world's first OS to run on a 64 bit platform. The Alpha.
http://www.netbsd.org/Ports/alpha/
Linux came way later.
FreeBSD also runs on Alpha and is currently being tested on IA-64 and AMD64.

-kwag
Reply With Quote
  #12  
01-06-2004, 08:19 PM
BobNET BobNET is offline
Free Member
 
Join Date: Sep 2003
Location: Ontario, Canada
Posts: 67
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to BobNET
Don't forget about the UltraSparcII... we had a whole lab of 300MHz Ultra 5 workstations put in in 1999 and they blew away all the other systems at the school (except possibly the 450MHz P3s from IBM, which were mainly used to play Quake 3 )

But AMD64 and PowerPC G5 processors are the first 64-bit systems readily available and cheap enough for home users...

Alpha systems were cool, though (still would be, but I think they stopped production on them). I remember reading about them in high school and thinking "1GHz processors! I'll never have one that fast!" They're still the best for numeric computations (although the Itanium processors are supposed to be as good or better, I haven't had the chance to use one though)...
__________________
--
Chris "Bob" Odorjan
Reply With Quote
  #13  
01-06-2004, 10:33 PM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Yeah, the UltraSparcII and the Alphas are really cheap now at E-Bay
I bought a couple of "Multias" a couple of years ago, and I installed NetBSD on them. They were SLOWWWW and hot
But the worked fine as a small ftp and web server.
NetBSD should run really great on the Sparcs. I've been told that NetBSD on Sparc runs circles around Linux (on the same machine)
As a matter of fact, NetBSD and FreeBSD (not Linux!) are being used here: http://ctd.lerc.nasa.gov/5610/tcpextensions.html extensively

-kwag
Reply With Quote
  #14  
01-07-2004, 12:29 AM
BobNET BobNET is offline
Free Member
 
Join Date: Sep 2003
Location: Ontario, Canada
Posts: 67
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to BobNET
Quote:
Originally Posted by Kwag
NetBSD should run really great on the Sparcs. I've been told that NetBSD on Sparc runs circles around Linux (on the same machine)
I somehow ended up with a SparcStation 5 (170MHz TurboSparc processor, unfortunately only 32-bit). It runs OpenBSD and is used mainly as a router/firewall... never tried Linux on it since BSD worked right from the start.

Quote:
As a matter of fact, NetBSD and FreeBSD (not Linux!) are being used here: http://ctd.lerc.nasa.gov/5610/tcpextensions.html extensively
Talking to satellites with TCP... reminds me of this comment from the Linux kernel (net/ipv4/tcp_timer.c):

Code:
        /* Increase the timeout each time we retransmit.  Note that
         * we do not increase the rtt estimate.  rto is initialized
         * from rtt, but increases here.  Jacobson (SIGCOMM 88) suggests
         * that doubling rto each time is the least we can get away with.
         * In KA9Q, Karn uses this for the first few times, and then
         * goes to quadratic.  netBSD doubles, but only goes up to *64,
         * and clamps at 1 to 64 sec afterwards.  Note that 120 sec is
         * defined in the protocol as the maximum possible RTT.  I guess
         * we'll have to use something other than TCP to talk to the
         * University of Mars.
         *
         * PAWS allows us longer timeouts and large windows, so once
         * implemented ftp to mars will work nicely. We will have to fix
         * the 120 second clamps though!
         */
__________________
--
Chris "Bob" Odorjan
Reply With Quote
  #15  
01-07-2004, 12:50 AM
kwag kwag is offline
Free Member
 
Join Date: Apr 2002
Location: Puerto Rico, USA
Posts: 13,537
Thanks: 0
Thanked 0 Times in 0 Posts
Quote:
Originally Posted by BobNET

Talking to satellites with TCP... reminds me of this comment from the Linux kernel (net/ipv4/tcp_timer.c):

Code:
        /* Increase the timeout each time we retransmit.  Note that
         * we do not increase the rtt estimate.  rto is initialized
         * from rtt, but increases here.  Jacobson (SIGCOMM 88) suggests
         * that doubling rto each time is the least we can get away with.
         * In KA9Q, Karn uses this for the first few times, and then
         * goes to quadratic.  netBSD doubles, but only goes up to *64,
         * and clamps at 1 to 64 sec afterwards.  Note that 120 sec is
         * defined in the protocol as the maximum possible RTT.  I guess
         * we'll have to use something other than TCP to talk to the
         * University of Mars.
         *
         * PAWS allows us longer timeouts and large windows, so once
         * implemented ftp to mars will work nicely. We will have to fix
         * the 120 second clamps though!
         */
That's good. Really good
KA9Q, yeah, reminds me of my early days when I got my Extra Class Amateur license, and I did a lot of experimenting via HF bands with his program. I also used Mike Pechura's (WA8BXN) MSYS program, which was my first FTP experience via amateur radio, at 300 baud
Fun days
73's DE KP4QG

-kwag
Reply With Quote
Reply




Similar Threads
Thread Thread Starter Forum Replies Last Post
Linux: Avisynth, Codecs, Virualdubmod under Linux Prodater64 Computers 11 12-24-2005 07:54 AM
Kvcd en linux? moyati Convertir y Codificar Video (Español) 5 05-05-2004 12:43 AM
Linux: Dyne:bolic GNU/Linux Distribution kwag Computers 4 03-10-2004 09:56 PM
Linux: Redhat Linux is dead, long live Fedora Core 1 jorel Computers 1 09-28-2003 04:05 PM
Kvcd and Linux? serrabastien Video Encoding and Conversion 1 02-13-2003 01:15 PM

Thread Tools



 
All times are GMT -5. The time now is 08:38 AM  —  vBulletin © Jelsoft Enterprises Ltd