Alas Python is no longer "real" ... lives in a horrible "virtual
environment" that seems to lock out a lot of useful stuff "for your
safety".
On Sun, 8 Mar 2026 05:31:16 -0400, c186282 wrote:
Alas Python is no longer "real" ... lives in a horrible "virtual
environment" that seems to lock out a lot of useful stuff "for your
safety".
I started using venvs long ago but it is getting more painful. One thing I've started doing is
rbowman <[email protected]> writes:
On Sun, 8 Mar 2026 05:31:16 -0400, c186282 wrote:
Alas Python is no longer "real" ... lives in a horrible "virtual
environment" that seems to lock out a lot of useful stuff "for your
safety".
I started using venvs long ago but it is getting more painful. One
thing I've started doing is
If c186282 actually means venvs, and doesn’t want to be in one, then ‘deactivate’ is all they need.
However, the idea that Fedora 43 pushes Python into a venv by default
does not pass the sniff test (and doesn’t seem to be true in the
container image, which has what looks like a perfectly normal Python
3.14).
Perhaps they have confused it with something else.
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling packaging systems’ mess, and looks like it’s straightforward to override the restriction if appropriate.
On 2026-03-08, Richard Kettlewell <[email protected]d> wrote:
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling
packaging systems’ mess, and looks like it’s straightforward to override >> the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling packaging systems’ mess, and looks like it’s straightforward to override the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
On Sun, 08 Mar 2026 22:05:37 +0000, Richard Kettlewell wrote:
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling
packaging systems’ mess, and looks like it’s straightforward to override >> the restriction if appropriate.
I've gotten used to it and don't find it cumbersome but I also use dotnet, express, arduino_cli that generate the skeleton of a project.
I've never tried a package that Fedora wants to install to the user's
space. Arch generates an error similar to the Ubuntu one. ruff isn't a
good test on either of those since both distros have a python-ruff package that can be installed with dnf or pacman. I don't know why Ubuntu doesn't since ruff is a general purpose tool like black. The PEP does say distros roll their own. As the distros use more Python behind the scenes they have
a real interest in people not randomly installing to the system packages.
I fired up the Leap 16 VM and it gives the same external message as
Fedora. 'sudo zypper install python3-ruff' works on that too.
There may still be more forgiving distros but with the Debian, Arch,
Fedora, and SUSE families working mostly the same I think C12345 better embrace venv.
On 3/8/26 20:27, Charlie Gibbs wrote:
On 2026-03-08, Richard Kettlewell <[email protected]d> wrote:
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling
packaging systems’ mess, and looks like it’s straightforward to override
the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
At some point the 'idealists' can degrade and ruin
a perfectly good thing. The idea of a Python VE is
a stone on this road to ruin.
Oh well, I've done a lot of Pascal and 'C' ... so
as needed I can go there. Python IS super handy
however and has a a lib for everything.
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise it's
back to writing Yet Another C Program.
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise
it's back to writing Yet Another C Program.
On 2026-03-09, c186282 <[email protected]> wrote:
On 3/8/26 20:27, Charlie Gibbs wrote:
On 2026-03-08, Richard Kettlewell <[email protected]d> wrote:
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt >>>>> to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling
packaging systems’ mess, and looks like it’s straightforward to override
the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but
this discussion is scaring me off. To quote the old Depression-era
saying: "Is this trip really necessary?"
At some point the 'idealists' can degrade and ruin
a perfectly good thing. The idea of a Python VE is
a stone on this road to ruin.
Oh well, I've done a lot of Pascal and 'C' ... so
as needed I can go there. Python IS super handy
however and has a a lib for everything.
I did write a little Python program that played with the
various GUI gadgets that it made available (with much less
effort than doing it in C). It made me think that I could
write something that my wife might actually be able to use.
(I was careful to use Python 3, not 2.) It would be nice
if this remained a viable option; otherwise it's back to
writing Yet Another C Program.
Charlie Gibbs <[email protected]d> wrote:
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise it's
back to writing Yet Another C Program.
Not necessarially. If the "GUI gadgets" were from the Tkinter package,
then the GUI gadgets were actually Tk widgets from the TCL world. So
you could also sidestep all the python venv silliness by writing that
GUI in TCL instead (and if it's just calling out to other programs to
do the real work, the amount of TCL necessary to glue a GUI to another program is small).
On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise
it's back to writing Yet Another C Program.
C would only be better if you could somehow get by with fewer
dependencies than with the Python equivalent. I’m not sure how you
would manage that -- reinvent more of your own wheels, perhaps?
On 3/8/26 23:55, Lawrence D’Oliveiro wrote:
On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it
in C). It made me think that I could write something that my wife
might actually be able to use. (I was careful to use Python 3, not
2.) It would be nice if this remained a viable option; otherwise
it's back to writing Yet Another C Program.
C would only be better if you could somehow get by with fewer
dependencies than with the Python equivalent. I’m not sure how you
would manage that -- reinvent more of your own wheels, perhaps?
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
Oddly, in the huge net universe, I can't seem to find a good clean
generic way to DEFEAT the venv,
not even for Linux. Most advice mentions CL shit that doesn't
work/exist.
On 2026-03-08, Richard Kettlewell <[email protected]d> wrote:
rbowman <[email protected]> writes:
You don't necessarily have to use a venv if what you're doing is
covered by the standard Python packages but there is a strong attempt
to herd you into a venv.
The design seems better than defaulting to getting into a ‘duelling
packaging systems’ mess, and looks like it’s straightforward to
override the restriction if appropriate.
This thread has been making my eyes glaze over. I was thinking of
writing a small utility in Python to get to know the language, but this discussion is scaring me off. To quote the old Depression-era saying:
"Is this trip really necessary?"
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it in
C).
It made me think that I could write something that my wife might
actually
be able to use.
(I was careful to use Python 3, not 2.) It would be nice if this
remained a viable option; otherwise it's back to writing Yet Another C Program.
I've written 5000 line Python apps ... one smart backup app maybe a
bit longer. It is a very versatile lang, mostly self-documenting,
plus tons and tons of online doc/examples.
But they seem to be ruining it ....
On Sun, 8 Mar 2026 21:14:00 -0400, c186282 wrote:
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I disagree. VEs save you from the equivalent of dll hell someplace down
the road. Dotnet, Angular, Node, and others are similar now. Your project encapsulates the dependencies it needs. Another project may require different versions. For example with node anything you install for the project goes into node_modules and package.json has the dependencies for that project:
"dependencies": {
"cookie-parser": "~1.4.4",
"debug": "~2.6.9",
"express": "^4.21.2",
"fs": "^0.0.1-security",
"leaflet": "^1.9.4",
"leaflet-gpx": "^2.2.0",
"morgan": "~1.9.1"
}
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it in
C). It made me think that I could write something that my wife might
actually be able to use. (I was careful to use Python 3, not 2.)
It would be nice if this remained a viable option; otherwise it's
back to writing Yet Another C Program.
Stick to tkinter and you *should* be good. I say should because 'import tkinter' works on Mint, Ubuntu, and Fedora. On Leap you'd have to do
'zypper install python-tk' but it would then be global. Arch says it's python isn't configured for Tk.
On 2026-03-09, rbowman <[email protected]> wrote:
On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it in
C). It made me think that I could write something that my wife might
actually be able to use. (I was careful to use Python 3, not 2.)
It would be nice if this remained a viable option; otherwise it's back
to writing Yet Another C Program.
Stick to tkinter and you *should* be good. I say should because 'import
tkinter' works on Mint, Ubuntu, and Fedora. On Leap you'd have to do
'zypper install python-tk' but it would then be global. Arch says it's
python isn't configured for Tk.
My little test program uses tkinter, and runs fine on Debian Bookworm.
Looks like a good start...
On 2026-03-09, rbowman <[email protected]> wrote:
On Mon, 09 Mar 2026 02:47:51 GMT, Charlie Gibbs wrote:
I did write a little Python program that played with the various GUI
gadgets that it made available (with much less effort than doing it in
C). It made me think that I could write something that my wife might
actually be able to use. (I was careful to use Python 3, not 2.)
It would be nice if this remained a viable option; otherwise it's
back to writing Yet Another C Program.
Stick to tkinter and you *should* be good. I say should because 'import
tkinter' works on Mint, Ubuntu, and Fedora. On Leap you'd have to do
'zypper install python-tk' but it would then be global. Arch says it's
python isn't configured for Tk.
My little test program uses tkinter, and runs fine on Debian Bookworm.
Looks like a good start...
c186282 <[email protected]> writes:
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
As Jon says, you’ve misdiagnosed your problem.
If you actually want someone to help solve your problem then you’ll have
to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.
Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.
I want the VENV *dead* ... CAN that be done ???
Or do I have to go back to 2020 versions of Linux ?
c186282 <[email protected]> writes:Then don't waste your time.
Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.
You’ve not reported anything actionable.
On Sun, 8 Mar 2026 21:14:00 -0400, c186282 wrote:
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I disagree. VEs save you from the equivalent of dll hell someplace down
the road. Dotnet, Angular, Node, and others are similar now. Your project encapsulates the dependencies it needs. Another project may require
different versions. For example with node anything you install for the project goes into node_modules and package.json has the dependencies for
that project:
"dependencies": {
"cookie-parser": "~1.4.4",
"debug": "~2.6.9",
"express": "^4.21.2",
"fs": "^0.0.1-security",
"leaflet": "^1.9.4",
"leaflet-gpx": "^2.2.0",
"morgan": "~1.9.1"
}
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <[email protected]> writes:
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
As Jon says, you’ve misdiagnosed your problem.
COULD be ...
But I still note that things that worked clean
and easy pre-VENV now DON'T.
Who/what should I blame ?
There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.
If you actually want someone to help solve your problem then you’ll have >> to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.
Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.
I want the VENV *dead* ... CAN that be done ???
On Sun, 8 Mar 2026 21:14:00 -0400, c186282 wrote:+1.
At some point the 'idealists' can degrade and ruin a perfectly good
thing. The idea of a Python VE is a stone on this road to ruin.
I disagree. VEs save you from the equivalent of dll hell someplace down
the road.
In comp.os.linux.misc c186282 <[email protected]> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <[email protected]> writes:
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
As Jon says, you’ve misdiagnosed your problem.
COULD be ...
But I still note that things that worked clean
and easy pre-VENV now DON'T.
Who/what should I blame ?
There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.
If you actually want someone to help solve your problem then you’ll have >>> to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.
Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.
I want the VENV *dead* ... CAN that be done ???
And, again, much as Jon said, you are blaming "venv's" but given us no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.
On 3/10/26 10:55, Rich wrote:
In comp.os.linux.misc c186282 <[email protected]> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <[email protected]> writes:
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
As Jon says, you’ve misdiagnosed your problem.
COULD be ...
But I still note that things that worked clean
and easy pre-VENV now DON'T.
Who/what should I blame ?
There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.
If you actually want someone to help solve your problem then you’ll have >>>> to accurately describe what you are trying and what is happening. In
practice this means posting the exact code you are using and exactly
what happens when you run it.
Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.
I want the VENV *dead* ... CAN that be done ???
And, again, much as Jon said, you are blaming "venv's" but given us no
examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.
Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)
Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.
On 3/10/26 10:55, Rich wrote:
And, again, much as Jon said, you are blaming "venv's" but given us
no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python
than you do, something to analyze and maybe show you where the
problem really exists.
Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)
Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.
On 3/10/26 10:55, Rich wrote:
In comp.os.linux.misc c186282 <[email protected]> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <[email protected]> writes:
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
As Jon says, you’ve misdiagnosed your problem.
COULD be ...
But I still note that things that worked clean and easy pre-VENV
now DON'T.
Who/what should I blame ?
There's no POINT in a 'virtual environment/machine' unless you
PLAN to isolate the base machine from the application to various
degrees.
If you actually want someone to help solve your problem then
you’ll have to accurately describe what you are trying and what is
happening. In practice this means posting the exact code you are
using and exactly what happens when you run it.
Too fuckin' old now, not gonna get into a million details and
sub-sub-sub-config-files. I just report that some lower-level
OS commands no longer work as expected, or at all, using the
usual Python utilities for doing so.
I want the VENV *dead* ... CAN that be done ???
And, again, much as Jon said, you are blaming "venv's" but given us
no examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python
than you do, something to analyze and maybe show you where the
problem really exists.
Can't figure out how to zap the VENV in order to provide the
examples you'd like :-)
Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)
Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.
Hmmm ... Python worked GREAT *before* the VENV ...
no 'hell'.
Or do I have to go back to 2020 versions of Linux ?
Can't figure out how to zap the VENV in order to provide the examples
you'd like
Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.
I predict no such example will be posted, since you seem to want to
bitch and complain about things you don't want to understand more than
you want to know why your system call isn't working.
On 2026-03-10, c186282 <[email protected]> wrote:
On 3/10/26 10:55, Rich wrote:
In comp.os.linux.misc c186282 <[email protected]> wrote:
On 3/9/26 09:59, Richard Kettlewell wrote:
c186282 <[email protected]> writes:
The Python VENV *seems* to be thwarting my
ability to run certain hard-core system
routines via "os.system()" or related. The
'virtual' seems to be for idiot 7-year-olds
you don't want to crash the box.
Well, sometimes, I *want* to crash the box.
As Jon says, you’ve misdiagnosed your problem.
COULD be ...
But I still note that things that worked clean
and easy pre-VENV now DON'T.
Who/what should I blame ?
There's no POINT in a 'virtual environment/machine'
unless you PLAN to isolate the base machine from
the application to various degrees.
If you actually want someone to help solve your problem then you’ll have
to accurately describe what you are trying and what is happening. In >>>>> practice this means posting the exact code you are using and exactly >>>>> what happens when you run it.
Too fuckin' old now, not gonna get into a million
details and sub-sub-sub-config-files. I just report
that some lower-level OS commands no longer work
as expected, or at all, using the usual Python
utilities for doing so.
I want the VENV *dead* ... CAN that be done ???
And, again, much as Jon said, you are blaming "venv's" but given us no
examples to support your assertion. It is *very likely* that you
indeed are blaming the wrong thing. How about creating a very short
example that works without a venv but fails within one, and posting
that example. That will give others, who may know far more python than
you do, something to analyze and maybe show you where the problem
really exists.
Can't figure out how to zap the VENV in order
to provide the examples you'd like :-)
Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.
This not only isn't true, it cannot be true, because *by definition*
if the environment you're seeing is the same one Python always sees
then it isn't a "virtual" environment, it's the system environment.
OK, tomorrow, HOW do I start a Py3 that's NOT in the VENV ???
Go ahead, search - I have. All the 'fixes' don't work anymore.
Many say "no problem" - yet NO current workarounds.
On Tue, 10 Mar 2026 06:21:17 -0400, c186282 wrote:
Hmmm ... Python worked GREAT *before* the VENV ...
no 'hell'.
Until it didn't. The install of the Esri desktop included a Python2.7 directory that had Python with their secret sauce added. It did not play
well if you had Python from python.org installed. When they finally
migrated to Python 3 they used conda for the installation. That REALLY
didn't play well.
Then there was ActiveState Python, originally designed for Windows with packages to leverage the Windows API. They also had a Perl installation.
Sure, you could use Python casually and not run into any problems. You
still can if you don't want packages that aren't included in the distro's site-packages.
On 3/10/26 13:09, Jon Ribbens wrote:
On 2026-03-10, c186282 <[email protected]> wrote:
Can't figure out how to zap the VENV in orderThis not only isn't true, it cannot be true, because *by definition*
to provide the examples you'd like :-)
Seems like, of late, it's entirely baked-in -
Python is the VENV and the VENV is Python.
if the environment you're seeing is the same one Python always sees
then it isn't a "virtual" environment, it's the system environment.
OK, tomorrow, HOW do I start a Py3 that's NOT in
the VENV ???
Go ahead, search - I have. All the 'fixes' don't
work anymore.
Many say "no problem" - yet NO current workarounds.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,099 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492372:10:21 |
| Calls: | 14,105 |
| Calls today: | 1 |
| Files: | 187,124 |
| D/L today: |
1,228 files (559M bytes) |
| Messages: | 2,495,990 |