Actually, it's not just the file system that eats space that leads to
a 500GB disk being shown at just over 400GB.
It's also determined by how the manufacturer measures 1K of data.
Some manufacturers in order to inflate their drive values, treat a K
as 1,000 bytes. This is not accurate. 1K is actually 1024 bytes.
When you're talking about GB size ranges, this leads to huge
descrepincies in rated vs actual sizes. Thats why I like the Lasie
drives, they rate according to a 1024 byte K, and so their drives are
always very close to the rated size, whereas 1 500GB drive I bought
(manufacturer will remain nameless) was actually a 435GB drive, which
made me *very* angry.
If they want to claim 1000 bytes is 1K, then they should be required
to say so somewhere on their packaging. I happily would have paid the
extra 20 bucks, and got something that was closer to the actual 500GB
mark if I had known.
On Feb 12, 2009, at 7:06 AM, OCTAGRAM wrote:
Where are discussions about it occuring? I'd like to follow your
progress.
Maybe we could share some thoughts.
In AdaStep (aka gnat-cocoa) there is a problem with GC. Turning GC
on is
probably not an option at the moment. Classes created by Objective-C
compiler are binary-documented by compiler, but Ada ancestors are
not going
to be unless someone write ASIS utility to parse Ada sources.
Personally, I am all against GC. People complain loudly when
discover that
their new 500Gb HDD is detected as 418Gb or so. Decimal/hexadecimal
Gbs, FS
structures, 10% reserved for root -- this all adds to storage
losses. People
complain when they lose 8-30%. How happy can such a man be knowing
that GC
program can effectivelly use just 20%-40% out of his operative memory
(loosing 60-80%)?
I can think of solution like having two internal arrays of strong
and weak
references. To mark an array is simpler than arbitrary Ada object
layout.
And there still probably remain bounded errors. Boehm's heuristic
behaviour
on untyped objects doesn't sound good to me.
Life would be much easier if one did not have to overlay non-GC PLs
on top
of GC ones.
In .NET doing this is a bit simpler: .NET objects can be accessed
through a
COM. .NET wrappers correctly respond to AddRef and Release methods.
Apple
website states that retain and release do nothing in GC environment:
http://developer.apple.com/leopard/overview/objectivec2.html
With garbage collection enabled, the older reference count memory
management
methods of retain, release, and autorelease have no effect.
I'm asking those who has Leopard, how much does programmer lose
denying GC?
May be GC is not worth bothering about.
--
View this message in context:
http://www.nabble.com/PasCocoa-design-tp21975675p21975675.html
Sent from the Free Pascal - General mailing list archive at
Nabble.com.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
