Computers:

dash wrote:

Shelby wrote:I wrote a huffman encoder in HaXe (Flash, etc) for JPEG in 2008

Finally you may have actually contributed something that is useful to me. I've never heard of HaXe. I've often wanted to author flash files but want to use open source tools using traditional unix-style Makefile, text editing, etc. (as opposed to point and click user interfaces). Maybe this HaXe is the ticket.

Thanks!

Shelby wrote:, note that Copute aims to be the holy grail upgrade from HaXe, and I had initially planned to compile to HaXe, so therefor Flash, PHP, C++, JavaScript, Nevo VM, and (soon) Java would all be targets.

SRSrocco wrote:DASH...good to see you are still alive.

dash wrote:

Shelby wrote:, note that Copute aims to be the holy grail upgrade from HaXe, and I had initially planned to compile to HaXe, so therefor Flash, PHP, C++, JavaScript, Nevo VM, and (soon) Java would all be targets.

June 2008 I wrote a BASIC interpreter...

So I reimplemented the entire interpreter. I made a Bison (Yacc) grammar and had the parser output virtual machine code for a stack based virtual machine which I also implemented...

I'm sure you must be familiar with Bison. You'd want to use that approach if you want to build your Copute compiler.

dash wrote:I learned how to program with BASIC first. I was able to "overcome" the bad practices that BASIC leads to. And having that experience I was able to realize the value of the improvements that came after BASIC. Why deny my kids that evolutionary history?...

Shelby wrote:...Nanotech minature bots which might reduce the cost (and energy cost) of mining gold by orders-of-magnitude enabling lower grades to be extracted at accelerated rates, thus destroying the stocks-to-flows principle.

At that point I'd be invested in nano-bots. I'm guessing this could take awhile and won't catch anyone by surprise.

Second, Singularity is built on and offers a new model for safely extending a system or
application’s functionality. In this model, extensions cannot access their parent’s code or data
structures, but instead are self-contained programs that run independently. This approach
increases the complexity of writing an extension, as the parent program’s developer must define a
proper interface that does not rely on shared data structures and an extension’s developer must
program to this interface and possibly re-implement functionality available in the parent.
Nevertheless, the widespread problems inherent in dynamic code loading argue for alternatives
that increase the isolation between an extension and its parent. Singularity’s mechanism works for
applications as well as system code; does not depend on the semantics of an API, unlike domain14
specific approaches such as Nooks [49]; and provides simple semantic guarantees that can be
understood by programmers and used by tools.

The principal arguments against Singularity’s extension model center on the difficulty of
writing message-passing code. We hope that better programming models and languages will
make programs of this type easier to write, verify, and modify. Advances in this area would be
generally beneficial, since message-passing communication is fundamental and unavoidable in
distributed computing and web services. As message passing becomes increasingly familiar and
techniques improve, objections to programming this way within a system are likely to become
less common.

Shelby aka Jocelyn wrote:Linus is correct that micro-kernel degenerates to a monolithic mush, unless there exists the system-wide solution that ultimately has to come from the language (virtual machine) layer. I have deduced that issue is most fundamentally that sharing a resource is security hole for the same reason that it kills inter-function/process composability scaling, i.e. it removes referential transparency. Apparently Microsoft Research is aware of this with their work on Singularity.

One of the big stumbling blocks for GNU Hurd (since at least 2002, if not 1992) appears to be that Unix is based around file/stream handles for accessing resources and devices. One referential INtransparency problem is how to pass around these handles securely between user mode processes:

http://www.opensubscriber.com/message/l4-hurd@gnu.org/12608235.html
http://www.coyotos.org/docs/ukernel/spec.html#frontmatter-2.2

Apparently the lack of asynchronous form of inter-process procedure call (IPC) in the micro-kernel complicates or reduces the performance of any solution in their view. Also the inability of the micro-kernel to enforce capability meta-data on shared resources (and the IPC call itself) is claimed to be a security hole and hindrance to solve in the user process layer.

Shelby aka Jocelyn wrote:Someone who 'cracks" is also contributing to the evolution of security and progress. If it is not a victim-less action, it probably carries some civil and/or criminal liability. The moral judgment is irrelevant to me as a scientist.

In general, using extremely high compression rate makes steganography difficult, but not impossible. While compression errors provide a hiding place for data, high compression reduces the amount of data available to hide the payload in, raising the encoding density and facilitating easier detection (in the extreme case, even by casual observation).

Shelby wrote:Does any one else hate the "Secret Question" password recovery techniques? The name of my first dog, where I was born, etc... are not secrets! Especially after I answer the same question on several websites (you think they are all perfectly secure??). I always answers these (if I am forced to answer) with gibberish, e.g. "kjhbjkuytv78wsdnjksnkjjn891gb ckj". Then I call or email support if I need password recovery.

Oh and in rebuttal to Forest Lane's last comment:

https://goldwetrust.forumotion.com/knowledge-f9/book-ultimate-truth-chapter-6-math-proves-go-forth-multiply-t159-15.htm#3748

The universe is always trending to more disorder, i.e. more independent actors and more possibilities. It will always outrun the centralized orders. That is the definition of natural law.

goldwave wrote:From Paul Rosenberg the CEO of Cryptohippie USA, the leading provider of Internet anonymity.

http://cryptohippie.com/

http://www.lewrockwell.com/orig11/rosenberg-p1.1.1.html

1. It is impractical for them to enforce that proposed wiretap backdoor legislation, people will simply move to P2P and rogue anonymous software for doing so. This will be effective against large, popular sites though.
   
2. "Internet kill switch" is technically impractical, because TCP/IP is self-healing and will route around any networks that are taken down. They can kill major arteries, but the internet will go virally P2P in a very short time.
   
3. Technically, SecureBGP (BGPSEC) can't be widely implemented because it won't scale well beyond the major arteries. Ad hoc routing with TCP/IP will route around it, if it becomes a block (nature sees it as non-functional and routes around due to Coase's Theorem). The fact that BGP is P2P now, means that it will be impossible to go back to making it centralized.
   
4. Regarding intellectual property policing, a decentralized DNS is feasible and will be incentivized by the govt's fascism.
   
5. All of this is like the Napster experience-- the more the authorities attacked, the more P2P alternatives popped up and the more people that participated in downloading music for free. The govt is powerless (as usual), but they will hold sway over the large sites and arteries.
   
6. "Computer health certificate" is so impossible, I really doubt the competence of the author of the link you provided.
   
7. Cloud computing can be P2P, I am working on it: https://goldwetrust.forumotion.com/knowledge-f9/book-ultimate-truth-chapter-6-math-proves-go-forth-multiply-t159-15.htm#3640
   

Linus Torvalds wrote:Anybody who has ever done distributed programming should
know by now that when one node goes down, often the rest
comes down too. It's not always true (but neither is it
always true that a crash in a kernel driver would bring
the whole system down for a monolithic kernel), but it's
true enough if there is any kind of mutual dependencies,
and coherency issues.

And in an operating system, there are damn few things that
don't have coherency issues. If there weren't any coherency
issues, it wouldn't be in the kernel in the first place!

(In contrast, if you do distributed physics calculations,
and one node goes down, you can usually just re-assign
another node to do the same calculation over again from
the beginning. That is not true if you have a
really distributed system and you didn't even know where
the data was coming from or where it was going).

Linus Torvalds wrote:>To be fair even in monolithic kernels it is not easy
>to share data given races on SMP/preemption etc.

Nobody claims that threaded programming is easy.

But it is a hell of a lot easier if you can use a lock
and access shared data than if you have to use some
insane distributed algorithm. It's usually many orders
of magnitude easier in monolithic kernels.

Synchronizing some data in a monolithic kernel may
involve using a lock, or special instructions that do
atomic read-modify-write accesses. Doing the same in
a microkernel tends to involve having to set up a whole
protocol for communication between the entities that
need to access that data, or complex replication schemes
(or they just end up mapping it into every process space,
just to avoid the problem. Problem solved, by just
admitting that separate address spaces was a mistake)

>Usually you need to design a locking protocol, care
>about livetime issues etc. It's all not simple there
>neither.

Nobody says kernels are easy. We're talking purely about
the relative costs. And microkernels are harder.
Much harder.

>I always admired how elegant some of parallel Erlang
>programs look and they use message passing
>so you certainly can do some stuff cleanly with
>messages too.

Not efficiently, and not anything complex.

It's easy and clean to use messages if you don't have
any truly shared data modified by both entities.

But the whole point of a kernel tends to be about shared
data and resources. Memory pressure? How do you free
memory when you don't know what people are using it for?

You can try to do an OS in Erlang. Be my guest. I'll be
waiting (and waiting.. The point being - you can't do
a good job).

Let's try an analogy. I'm not sure it's a great analogy,
but whatever:

In the UNIX world, we're very used to the notion of having
many small programs that do one thing, and do it well. And
then connecting those programs with pipes, and solving
often quite complicated problems with simple and independent
building blocks. And this is considered good programming.

That's the microkernel approach. It's undeniably a really
good approach, and it makes it easy to do some complex
things using a few basic building blocks. I'm not arguing
against it at all.

BUT IT IS NOT REALISTIC FOR ALL PROBLEMS. It's a really
really good way to solve certain problems. I use
pipelines all the time myself, and I'm a huge believer.
It works very well indeed, but it doesn't work very well
for everything.

So while UNIX people use pipelines for a lot of important
things, and will absolutely swear by the "many small
and independent tools", there are also situations where
pipelines will not be used.

You wouldn't do a database using a set of pipes, would you?
It's not very efficient, and it's no longer a simple flow
of information. You push structured data around, and you
very much will want to access the database directly (with a
very advanced caching mapping system) because not doing so
would be deadly.

Or, to take another example: you may well use a typesetting
system like LaTeX in a "piped" environment, where one tool
effectively feeds its input to another tool (usually through
a file, but hey, the concept is the same). But it's not
necessarily the model you want for a word processor, where
the communication is much more back-and-forth between the
user and the pieces.

So the "many small tools" model works wonderfully well,
BUT IT ONLY WORKS FOR A NICELY BEHAVED SUBSET OF YOUR
PROBLEM SPACE. When it works, it's absolutely the right
way to do things, since you can re-use components. But
when it doesn't work, it is just a very inconvenient
model, and while it's certainly always possible to
do anything in that model (set up bi-directional sockets
between many different parts), you'd have to be crazy to
do it.

And that's a microkernel. The model works very well for
some things. And then it totally breaks down for others.

Linus Torvalds wrote:For the last year or so, the new magic world has been
"security". It appears as totally bogus as the "ease of
maintenance" tripe was (and for largely the same reasons:
security bugs are often about the interactions
between two subsystems, and the harder it is to write
and maintain, the harder it is to secure).

I'm sure that ten years from now, it will be something else.

There's always an excuse.

Linus Torvalds wrote:The whole "make small independent modules" thing just sounds
like manna from heaven when you're faced with creating an
OS, and you realize how daunting a task that is. At
that point, you can either sit back and enjoy the ride
(which I did - partly because I didn't initially really
realize how daunting it would be), or you can seek mental
solace in an idea that makes it sound easier than it is.

Linus Torvalds wrote:As I already alluded to (and expanded on in my reply to
myself), I actually think using "designer languages" may
be a much better solution to the modularity problem than
the microkernel approach. The C model is very much one
where you have to do all the modularity by hand (which
Linux does, btw - don't get me wrong).

Shelby wrote:>>This really resolves to who makes money in the ecosystem, the app vendors (iOS) or the handset makers (Android).
>
> You came in late, so maybe you haven’t seen my analysis of Google’s grand strategy. You should probably read this and this for starters.

Check my logic please?

Some users are unwilling to pay $50+ for a new OS every time they buy a new computer, unless it is hidden in the cost of the new computer, because they are not getting any significant innovation. Evidence the number of users preferring to run Windows XP SP2, especially in the developing world as it is much easier to steal than Vista or Windows 7-- just patch it and turn off Windows Update.

Closed-source code strangles itself because it fights against innovation of itself. The vested interest is in the past, not in the optimum future.

>> You don’t think in the future that people will have similar amounts of money (relative to the cost of the unit) tied up into their phones as they do for their computers?
>
> No, because I have yet to buy an app. So far, everything I’ve been able to identify that I wanted has been available for free.

Let me peer into a possible future.

Selling many little innovations separately doesn't scale, i.e. users can't be bothered with the hassle of micro-payments, e.g. imagine making a $0.0001 fractional cents payment decision on every URL clicked, implying Apple's AppStore isn't capitalizing on but a fraction of potential innovation. And large open source projects don't scale revenue sharing out to multitudes of random contributions (thus are not maximizing potential innovation). Imagine instead $12 a year (total for all the apps they use) from each of 100s of millions of users of a computer or smart phone, with that revenue distributed proportionally to every contributor, given some unifying (open source!) paradigm for monetizing those myriad of innovations. Imagine that increasing to $50+ per year, as competition between applications forced unification into that paradigm, thus increasing the value to the user. The userbase and the value (cost) per user would be both be increasing. Imagine that paradigm won because of an (key fundamental computing theory) economic benefit of a "designer" programming language that rendered existing languages and operating systems (including Linux) uncompetitive, precisely because it enabled fine-grained contribution scaling.

Shelby at jasonhommelforum.com wrote:...People rave about Python's conflation of indenting and grammar. Geez that is a step backwards to 30 years ago. Copute does it mathematically correct (all conflation removed from the grammar -> semantic translation layer) as per the prior post...

Code:

if foo:
    if bar:
        print 'Inner True'
    else:
        print 'Inner False'
else:
    print 'Outer False'

Code:

if test1: if test2: print x

Code:

if test if test2 print x
if test {if test2 print x} else print y

Code:

if test
  if test2 print x
if test {
  if test2 print x
} else
  print y

Code:

if x < y < z: print x; print y; print z

Code:

if x < y < z {print x print y print z}

Code:

if x < y < z: print x; print y print z

Code:

if x < y < z {print x print y} print z

Code:

if x < y < z: print x print y print z # Python

Code:

if x < y < z print x print y print z // Copute

Code:

if x < y < z {print x} print y print z

Any individual creation has its ideosyncracies,

and occasionally its creator has to justify these. Perhaps Python's most controversial feature is its use of indentation for statement grouping, which derives directly from ABC. It is one of the language's features that is dearest to my heart. It makes Python code more readable in two ways. First, the use of indentation reduces visual clutter and makes programs shorter, thus reducing the attention span needed to take in a basic unit of code.

Second, it allows the programmer less freedom in formatting, thereby enabling a more uniform style, which makes it easier to read someone else's code. (Compare, for instance, the three or four different conventions for the placement of braces in C, each with strong proponents.)

Code:

while x < y
  print x
print end

Code:

while x < y {
  print y
  print x
}
print end

Code:

while x < y {
  print y
  print x
}
while x < y
{
  print y
  print x
}
while x < y
  {
  print y
  print x
  }
if x < y {
  print y
  print x
} else print

Code:

while x < y:
  print y
  print x
if x < y:
  print y
  print x
else print

Code:

while x < y {
  print y
  print x
}
if x < y {
  print y
  print x
} else print

Code:

while x < y {
  print y
  print x }
if x < y {
  print y
  print x
} else print

This emphasis on readability is no accident. As an object-oriented language, Python aims to encourage the creation of reusable code.

Even if we all wrote perfect documentation all of the time, code can hardly be considered reusable if it's not readable.

Many of Python's features, in addition to its use of indentation, conspire to make Python code highly readable. This reflects the philosophy of ABC, which was intended to teach programming in its purest form, and therefore placed a high value on clarity.

Readability is often enhanced by reducing unnecessary variability. When possible, there's a single, obvious way to code a particular construct. This reduces the number of choices facing the programmer who is writing the code, and increases the chance that will appear familiar to a second programmer reading it.

Code:

if x:
.....print x

....print x
....if y:
........print y

Code:

if x:
    print x

print x
if y:
    print y

Code:

def myfunction(foo, bar):
....foo.boing()
...for i in bar.fizzle(foo):
......baz = i**2
....foo.wibble(baz)
....return foo, baz

Code:

def myfunction(foo, bar):
  foo.boing()
for i in bar.fizzle(foo):
  baz = i**2
foo.wibble(baz)
return foo, baz

Covariant assignment, e.g. T<Super> = T<Sub>, is allowed when the type T is read-only [...] Contravariant assignment, e.g. T<Sub> = T<Super>, is also allowed when T is write-only.

Function call expressions, which do not explicitly list the inferred types in their type parameter list, implicitly create polymorphic (i.e. potentially more than one) instantiations of a referentially transparent (aka pure) function declaration that does not contain 'typeof T', where T is an inferred type.

Whereas, function call expressions, which do not explicitly list the inferred types in their type parameter list, may only create one instantiation of a function declaration that either is referentially opaque (aka impure) or contains 'typeof T', where T is an inferred type. That implicit instantiation has the inferred type(s) of the first function call expression encountered by the compiler.

The point is that since referentially transparent (aka pure) functions have no side effects (not even internally retained state), there is no possible impact on the caller's state machine whether there one or more than one implicit instantiations of the function being called. Whereas, for example, given a function that saves an internal state (e.g. counter), then implicitly calling multiple instantiations would impact the caller's state machine differently than calling one instantiation. The ambiguity is because it is implicit, the programmer may not even be aware the code is calling more than one instantiation.