Hacker Newsnew | past | comments | ask | show | jobs | submit | vbit's commentslogin

This applies to loops as well. Numbers are objects that accept the `timesRepeat:` message:

    10 timesRepeat: [ n := n*2 ].
Not only that, you can send messages to blocks, to implement loops.

    [ n < 10 ] whileTrue: [ n := n + 1 ]


Compare to Ruby:

    10.times { n = n * 2 }
The latter isn't possible "out of the box", but easy enough to implement:

    class Proc
        def whileTrue; yield while self.call; end
    end

    # And use:
    n = 1
    ->{ n < 10 }.whileTrue { n = n + 1 } 

    puts n
Ruby syntax does get in the way of some of the more succint ways of defining control structures in Smalltalk, but the above shows some of the Smalltalk heritage of Ruby quite well, I think (though, while "10.times" is fairly idiomatic Ruby, implementing constructs like the one below certainly is not).


Anyone interested in playing around with Smalltalk can use https://pharo.org - I recently tried it and was pretty amazed with the quality of documentation available. It is quite a different experience working in an interactive live environment.


I briefly looked into it, but I can't seem to figure out what to make with it. It looked like you couldn't write an application with any portability, and any user would basically have to run a smalltalk vm to use your application. Am I mistaken?


This is my understanding, yes - http://wiki.c2.com/?ImageBasedLanguage . Some Lisp systems and the Factor language also work like this (though Factor does a lot of work to ensure that the contents of your image matches the code on disk). I believe it's possible to strip down your image for deployment so it only includes code required by your application.

Then again, we live in the era of Docker, in which it's commonplace to ship an entire Linux filesystem along with your web app. So shipping a Smalltalk VM (2.6MB for Pharo 5.0) shouldn't be too much of a stretch.


I'm no expert (not even close), but I believe they'd have to run Pharo itself, yes. So you could redistribute the Pharo runtime along with your app code (similar to, say, Python).

You may be able to build web applications too (http://seaside.st/).


There's also Kivy (http://kivy.org). Not with a sizeable sponsor like React or Xamarin, but it's Python :D


Would be nice to have a screenshot without the red squiggly underlines.


Unless..... "As you type in your program, the verifier constantly looks over your shoulders and flags any errors." .... it's a feature being highlighted =)


I have some projects in Mithril - is it worth it port to Vue?


Speaking only for myself, I'm sticking with Mithril.


> SMSs written to appear they are from someone that knows the recipient

I don't think this means they are sent from numbers known to the recipient. Only that the content is written such that it appears to be from someone who knows the recipient.

I don't know if actual spoofing is possible.


Yeah, if you look at the codebase it just selects a random string from an array of prewritten messages and sends that.


> When you send an e-mail today it’s sent in plaintext. This means that when you connect to your local coffee shop’s WiFi they can intercept all e-mail that is sent through their router. This is probably not the relationship you have with your barista…

Um, how many users use native clients on unencrypted ports as opposed to https based web-clients or TLS?


I manage e-mail servers used by "smaller" government users (individual agencies/offices, municipalities, and counties), schools, businesses and individuals -- those who are typically using a "real" mail client (e.g. Outlook) over web-based mail (although we offer that as well).

I haven't ran any type of extensive usage statistics but from what I see daily plain-text POP3 (i.e. 110/TCP) is overwhelmingly more popular than anything else. STARTTLS (with both POP3 and IMAP4) is a bit behind that, followed by {POP3,IMAP4}-over-TLS (i.e. 99{5,3}/TCP).

This is probably due to a mostly stable user base that doesn't reconfigure or set up new mail clients often. As new mail clients are installed / configured, they typically use "native TLS" (not STARTTLS) but I think this is likely because of the autoconfig/autodiscovery that most mail clients (especially mobile) support nowadays.

We will hopefully be completely doing away with plain-text mail "soon" but it will require a LOT of reconfiguring of mail clients.


A worrying number of small companies who hire "an IT guy" who will promptly install an unpatched old version of Exchange Server and only turn on POP3. (Yes, paying for Exchange and not having ActiveSync.)

This is why the best thing for most small companies is to just use hosted Google or Microsoft mail.


I don't have any stats, but I imagine lots of users still connect over unencrypted ports directly to their ISP. We have to remember that most users are not like the HackerNews demographics. If you have stats that points to this conclusion being wrong I'm happy to change my mind.


It looks like 80-85% of emails to/from Google are encrypted in transit, according to this page: https://www.google.com/transparencyreport/saferemail/

Encryption at rest is still a difficult UX/UI issue, but encryption during transit seems like something that most mail providers can get behind.


Note that this is MX-MX routing of emails between email providers, which sort have has to allow plaintext in practice.

The question of user-level IMAP/POP/SMTP access is different, but I'd expect somewhere in the region of 95+%. Note that the IMAP specification prohibits authentication that sends passwords in the plaintext [1] (although I don't know if the various IMAP servers permit AUTHENTICATE PLAIN before STARTTLS--checking, Outlook doesn't, and the other servers I had access to aren't open on 143 anyways), which means IMAP in practice requires SSL.

[1] The alternative is to use schemes like CRAM-MD5 or SCRAM-SHA-1 which don't send the password in plaintext, although these have become quite rare in practice.


Fortunately most ISPs and mail providers have disabled unencrypted logins. And many mail clients give really scary warnings if you try to use unencrypted imap or pop3.


...and how many people still use their ISP's mail as opposed to the "big" providers?


Probably many more than you expect.

I was certainly surprised by how many users there were when I took over responsibility for such mail systems five years or so ago.

In our case the answer is "thousands" -- and we're relatively small.


Could you please elaborate more on mithril vs. vue? Was it ease-of-use, performance or something else that pulled you over?


This is simply my highly subjective opinion, so take it for that, but it was really a number of factors.

Template format.

I actually really like Mithril's view format: it's an API built exactly as it should be -- to make using it very intuitive and natural. I also think it's a great solution technically, since it fluently combines a shorthand for generating HTML with data binding and lets you use native javascript (making it easy to build parts with functions or loops or whatever).

What I didn't like was actually working with it, as a lazy and mainly non-web developer. I like to copy and paste chunks of markup from bootstrap's documentation or other places. Recreating is fine for small things, but then I started porting pieces of another internal app that involved at least a couple hundred lines of HTML. There is(/was) a tool to convert, but it didn't work well enough to be usable for me.

I also realize there's MSX now, but I don't remember it at the time: I'm not sure if the documentation was lacking, or I was just tryin to avoid the complexity of a build tool for this (or both).

For my purposes, the only really fundamental difference between the two was the template format, and being able to stick HTML into Vue, add a couple attributes and have it work just worked better for me.

Community/Growth Potential

I felt the Vue community was bigger and growing more. The Mithril documentation was and continues to be great, but at least at the time there didn't seem to be much writing about it beyond the Mithril site.

Contrast to Vue, where it was easy to find many blog posts, StackOverflow questions/answers, etc.

I've used my share of frameworks/libraries that were later abandoned, and I really try to avoid that.


Often gets lost in the release notes - deploying on Google cloud is super easy:

    % gcloud compute instances create INSTANCE --image freebsd-11-0-release-p1-amd64 --image-project=freebsd-org-cloud-dev
    % gcloud compute ssh INSTANCE


That's really cool. They also provide official AMI imagex es and how to deploy on VAGRANT!

vagrant init freebsd/FreeBSD-11.0-RELEASE-p1


Wow, nice. Do you know how straightforward it is to get it with ZFS?


ZFS is native in FreeBSD, so it is exactly as straightforward as the above.


Even the last release supports full ZFS+encryption with the default installer.


This is still geli+zfs, and not native zfs encryption that was recently presented in OpenZFS Developer Summit [0].

[0] https://www.youtube.com/watch?v=frnLiXclAMo


Correct, it is full disk encryption instead of dataset encryption.

But on the other hand, if you install 11.0 from installer and chose Auto(ZFS) with EncryptedZFS and MBR(GPT) then you will get a GeliBoot installation. There is no boot pool anymore, instead the early boot stages decrypt the root zpool to load the rest of the boatloader, which then decrypts the pool to load the kernel. With bootloader-selectable boot environments.


...and I meant BIOS(GPT). Hmpf.


But you don't use the installer with "cloud" / VPS providers. It's usually more like cloning a VM image where the system is already installed.


If you're familiar with Python, try the Jupyter notebook (jupyter.org) - very useful for quick visualizations while also allowing you to quickly transform the data when necessary. The big advantage is your interactive 'repl' session is persisted as well as editable so you can resume anytime.

You can use any one of a number of visualization libraries such as matplotlib, bokeh, and more. Here's a quick start for an idea of the code needed: http://nbviewer.jupyter.org/github/bokeh/bokeh-notebooks/blo...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: